I am in the second year of my CS degree, and so far most of the projects I worked on were pretty "programming intensive", which I like. For example, developing a Sudoku solver, creating a database management system from scratch in C, implementing algorithms to find the shortest routes between cities and so on.

Recently I started working on some projects outside of my academic environment. Those include a web app and a couple of Android ones, which I shipped and got some people using.

What I noticed with those "real world" projects is that I spend much less time programming, and a lot more time learning about the platforms, searching the web for that library I need, trying stuff until it works the way I need, learning to use tools that might help on the project and so on. In other words, I end up writing 5 to 10 lines of code per day because the rest of the time is spent learning auxiliary stuff.

My question: Is this normal for real world projects, or once you master the platform you are working with you'll go back to programming intensive work?

Yes it is normal and those projects while they required time to finished were designed to be completed in a given short amount of time unlike real world projects which have a much larger timeline ( most of the time ) and in some cases the timeline is shorter then what is actually required to finish it ( tough luck you have to finish ).
–
RamhoundMay 23 '12 at 17:03

7

If you wrote another Android app do you think you would spend as much time learning the environment again? When using new technology the learning curve is always very steep but once you have the basics its becomes less about reading and finding and more about pulling out the tools you have previously built and using them.
–
Loki AstariMay 23 '12 at 17:55

In my experience, 90% of programming is gluing libraries together into applications or higher level libraries. It's only the remaining 10% that involves interesting algorithms. (And by "interesting" I mean other than "pass results of library A to library B".)
–
Steven BurnapMay 23 '12 at 20:20

It really depends what your job is. I'm pretty sure Eric Lippert doesn't spend 90% of his time gluing libraries together, of course 90% of programming averaged over all programmers probably is gluing libraries together as we can't all be on those sort of projects/products
–
jk.May 24 '12 at 6:32

Using libraries is a way to get more people on your team. Hence, it is very useful. Unfortunately they don't know that so it is only up to a certain degree.
–
user1249Jul 23 '12 at 6:12

Obviously the illustration is only meant to give you a basic idea of the various tasks you may find yourself involved with in a programming job. My own working patterns are extremely erratic, I don't think there is a "normal" level of coding in a professional environment, there are too many factors to consider, deadlines, team dynamics & composition, changes in requirements, bugs, fatigue (the dreaded burnout), etc.

Don't worry about it, programming is about problem solving, if you solve the puzzles your work presents you with and learn something new every now and then, your job is better than normal.

Are you implying the picture is a typical waterfall model, or that software development is typically waterfall in nature.
–
Loki AstariMay 23 '12 at 17:53

@LokiAstari That the illustration closely resembles a typical waterfall model, as far as over simplistic illustrations can resemble anything.
–
Yannis Rizos♦May 23 '12 at 17:55

@LokiAstari The "displayed here" part of the answer means that the image is a typical waterfall model. I'd call it more like, an ideal case of the waterfall model - Chinmay's loop is more accurate.
–
IzkataMay 23 '12 at 17:58

The programming challenge you are seeking will come from writing libraries, but you will not notice that you have created these until you are nearly done your project. The issue in the real world is that there is a high chance someone has already solved the problem you are facing and it is better to reuse the code they created. In terms of academia they are preparing you to be able to write these things on your own (the assumption being all knowledge could be lost tomorrow and you have to rebuild it).

A career in software development, like every other thing you might want to do with your life, is mostly about politics and surviving the drama llama than anything else. In fact, as an office job, software development ends up being mostly a game of politics and bullshit. Office Space isn't that far from the truth of things.

Oh, oh, and I almost forgot. Ahh, I'm also gonna need you to go ahead and come in on Sunday, too...
–
jfrankcarrMay 23 '12 at 22:32

Yes, sadly this is very much true. Just this week because we couldn't finish our SCRUM commitment in time, my boss asked me to work at night (without compensation in any way) to make sure all the user stories of the sprint will be completed. And please note: the only people that will see this release is "the business", the release will not be shows to our clients. At my current employer SCRUM isn't a tool anymore, instead it's the main product we're working on. I've learned my lesson: in the future I will commit to a lot less.
–
Wolfgang SchreursMay 25 '12 at 8:41

I don't have that problem so much, but a lot of developers are just so mouse like that a guy like me can have a hard time. I have opinions, I'm not afraid to argue about them... I like to get consensus and work with the team to provide the right solution. But people don't say what they want because they're afraid of feelings and then instead go to the boss and complain about you for doing things ways they don't like. Suggest a code piece should change and whoever wrote it gets all offended and crap. Say the word "crap" and get turned in to HR for being "hostile" (it was the example).
–
Crazy EddieMay 25 '12 at 15:39

2

One time my boss actually started crying and called me "ungrateful" because I wanted to know how an important piece of code worked and suggested the testers that used to test it didn't do as perfect a job as she thought. I quit that place. If I had to stay in late in an environment like that on an average basis... Luckily I get to go home after 8 hours pretty much every day except when we have some sort of major FUBAR. As a service provider when something breaks we're screwed and have to stay in..but that's only happened to me once so far.
–
Crazy EddieMay 25 '12 at 15:41

What I noticed with those "real world" projects is that I spend much less time programming, and a lot more time learning about the platforms, searching the web for that library I need, trying stuff until it works the way I need, learning to use tools that might help on the project and so on. In other words, I end up writing 5 to 10 lines of code per day because the rest of the time is spent learning auxiliary stuff.

Yup.

Here's how the bulk of my week goes:

Troubleshooting incident or problem reports: somebody reports a problem, I need to figure out a) whether it's really a problem, b) where the problem is occuring, and c) what steps need to be taken to fix it;

Preparing patches: we deploy updates once a week (although we'll be moving to biweekly, and then eventually monthly release cycles), and there's a nontrivial amount of process to follow. Forms have to be filled out and approved, installation and backout instructions have to be written, tarballs have to be staged, etc.;

Supporting other projects: for example, we have a disaster recovery test coming up, and I'm responsible for a few minor tasks (determining which clients to test against, filing change requests, etc.);

Sanity checking new installations: when we set up a new customer, my team does the initial round of QA, just to make sure we can connect and communicate with the customer's systems;

Go to various meetings (mostly short status meetings, occasional department or site meetings);

trying stuff until it works the way I need
This sounds a lot like programming. Maybe you're adjusting lines of code instead of creating new ones.

School projects are narrow enough in scope so they can be completed in a given amount of time. To be more 'real world' the professor should assign a project and then a few days later change it, but you'll learn that life sucks soon enough.

There will be times when you know exactly what needs to be done and how to do it (The specs are clear and you don't have to research a library.). Enjoy the moment. Pound away at your keyboard. Fight off the interuptions. This doesn't happen often enough, so enjoy it while you can. It will make you appreciate the times you're stuck in a meeting listening to senior-level managers discuss what label to put next to a text box for half an hour.

Very few programming jobs these days involve things like writing database or communications drivers from scratch, creating stack management algorithms and so forth. You may find some in a number of narrow fields, such as embedded software or game development. For the most part, you'll be using established frameworks and libraries to get work done, preferably quickly and accurately.

Also, more often than not, you'll find yourself working on corporate CRUD or reporting apps (web or desktop based) that help them do accounting, inventory, human resources management, etc. It's not as cool and exciting as working on the next Google or Facebook or the like but it will keep the bills paid.

In other words, I end up writing 5 to 10 lines of code per day
because the rest of the time is spent learning auxiliary stuff.

Colleges teach students how to write correct code. But in the "real world" you not only have to write correct code, but you need to write less code. Every line of code you don't write will save not only your time, but the time of people who'll work on it after you.

Is this normal for real world projects, or once you master the platform you are working with you'll go back to programming intensive work?

Somewhat. Getting blocking issues out of your way will allow you to write more code, but real world projects do tend to involve a lot of other issues (documentation, testing, maintenance, infrastructure, marketing, research, design) than school projects.