What Programming Is Like (As a Job, As an Activity & On Mondays)

A recent conversation with a coworker made me think about the gap between what programming is like for programmers and how non-programmers (read: normal people) imagine it to be. I think we as programmers (developers, coders, ninjas, samurai, whatever you want to call yourself) are so engulfed in our own world that we don’t even realize that other people may not have the slightest idea about what software development is really like. So I decided to give it a shot and try to explain this as best I can. I will keep it short.

There really is a thing called code

So first things first. If all you know about software development is based on hacking scenes in Hollywood movies, you might be under the impression that it’s something like a game, with 3d cityscapes and puzzles. And that’s exactly what it’s like! Except that there’s a lot less 3d, very few puzzles, a lot more text and it’s not a game…

There really is a thing called code that programmers write. It looks something like this:



The above is an excerpt from the source code of Toggl mobile application. The programming language is called C# (yes, the musical note). You can see all of the code here. The project is open source, meaning that the human-readable code (the source) is public for everyone to see and even to modify and extend under certain conditions.

The computer takes that human-readable code, compiles it into a computer-executable form and runs it.

There exists a plethora of different programming languages with different syntax and features. There are even languages that only compile into other languages!

Some languages are aimed towards web development, some for embedded systems (your toaster and refrigerator), others for mobile devices, etc. That doesn’t mean that you can’t cross those borders, however. It’s just that different environments set different requirements for the application and some languages are better suited than others.

Mandatory technical bit: the three main characteristics why you should choose one language over the other (in addition to subjective preference) are running speed, memory usage and development speed.

By running speed I mean the typical speed at which resulting program runs. The way a program is written affects this a lot as well, but if it’s speed you’re after you will probably choose your language accordingly.

Memory usage stands for the amount of memory a program will consume while it’s running, and you don’t want your program to hog all of your computer’s resources. Nowadays computers have so much memory that we don’t have to think about this as much as we used to, but it’s still an argument.

By development speed I mean the time it takes to write some piece of software in that language as well as the difficulty level in maintaining it later on. This is affected by various things such as language features and syntax, community support and the availability of libraries and frameworks.

What are libraries and frameworks? They are simply ready-made solutions to common problems that others have created and possibly open-sourced for you. For example, a library can be as simple as a utility package for doing date & time calculations (hehe veteran coders will notice the invalid use of ‘simple’ and ‘date & time calculations’ in the same sentence). A framework is more like a scaffold that sets up and forces or encourages you to use a certain kind of general architecture in your code.

Community support is needed because programmers actually spend lot of time googling for answers they either can’t figure out or just choose not to because googling is faster. Plus every once in a while the compiler decides to make your day interesting by outputting a cryptic error message that tells you almost nothing useful. In these situations it’s extremely helpful to find someone who knows the solution.

Here’s a cool poster showing the timeline of programming languages.

The History of Programming Languages - O'Reilly Media

The History of Programming Languages – O’Reilly Media

Notice how the timeline gets denser on the right side? This nicely visualises how the rate at which new languages, frameworks and libraries are created, is accelerating. Every new thing claims to be better than the last in some way. As new technologies find worldwide adoption, the older ones slowly wither away never to be used again (except in that legacy application your enterprise company is still using; maintaining it is growing more and more expensive but replacing it with newer technology even more so :D).

As a programmer you really do have to keep up with all this, otherwise you’re gonna miss out on all the new stuff that will make your life easier and you’re gonna find yourself on the lower end of the developer awesomeness scoreboard.

I recently spent 6 months away from web development and coming back I already felt like I was lagging behind.

What programming is like as an activity

I’ve talked a lot about what programming is, but not really what it’s like.
Programming as an activity (when you can do whatever you want), is exciting.

The closest thing I can think of that resembles programming something from scratch, is building something from Lego blocks.


It’s exciting because you can plan ahead and construct it any way you want. You can add structural integrity exactly where it’s needed while keeping it as light as possible. And because you’re an engineering genius, you know from the beginning that the end result is going to be perfect with everything right where it needs to be. Nothing more, nothing less. And what makes programming different from playing with legos is that you can actually create something out of nothing! How awesome is that?

More often than not, however, things don’t really go as planned and you end up with something that looks like that chopper on the left there, but it’s ok because that’s when you scrap the old project and start a new one from scratch again! #excited #lovingit 😀

What programming is like as a job

And since you’re getting pretty good and building helicopters, you decide to get a job as a lego engineer programmer.

So you’re excited to show off your skills on your new job, but your job will probably be mostly maintaining and building upon an already existing product, rather than creating a new one.

So you’re given this to work on:

Source: http://best360.deviantart.com/art/My-Huge-Lego-Ship-Front-Side-1994676

Source: http://best360.deviantart.com/art/My-Huge-Lego-Ship-Front-Side-1994676

…except that in the programming world, this really would be a fully working spaceship equipped with anti-gravity propulsion, warp drive, shields, guns and tractor beams.

So the manager decides to give you something simple for starters and refers you to a bug report ticket which says that laser turret B-12 sometimes tends to misfire when the tractor beam is active.

You dive into the blocks code.

Now, what you need to realize, is that software is not built like anything else… like cars for example. Cars are pretty much built the same way out of analogous parts and if you’re a mechanic, you can expect to be able to diagnose and fix most things on most cars. This is not the case with software. The structure of a piece of software depends solely on the decisions of the original author(s). Software is built more like ERROR #404: analogue not found.

What you find when start working on an existing piece of software can be best described with an image.

Pattaya, Thailand

Pattaya, Thailand

…except that it’s dark and you have a very very tiny flashlight.

‘Now why does it get that way?’ you might ask. ‘After all, all software projects get started as somebody’s exciting new project… I guess whoever made this, wasn’t such a genius lego engineer like me right?’

Well… he/she might have been the best developer in the world but things rarely go as planned. Perhaps there wasn’t enough time to do it right, so the main objective was to just ‘get it done’. Perhaps the client kept changing the requirements and the new requirements never really fit with the existing architecture and there was never enough time to refactor it. Also, when developing software, every new piece of it should be built in harmony with the rest of the existing architecture, but it’s very difficult to do that without a good overview of the existing architecture. Perhaps the reason for that mess is that the project saw too many new developers, each with their own ideas, no overview of the existing codebase and not enough time. The answer is probably ‘all of the above’.

And of course, since the project is more than a couple of months old, the cutting edge technologies that it uses are now obsolete.

So you dig through the code…

Source: http://abstrusegoose.com/432

Source: http://abstrusegoose.com/432

Eventually, you manage to fix laser turret B-12 (you do break the shields while doing so but you won’t know that until the customer files a bug report… oh… wait… no they won’t).

A stroke of luck! Your next task is building something from scratch. Yay you say! It’s not a big project, shouldn’t take more than a day… but that day happens to be a Monday.

What programming is like on a Monday

I will let my fellow developer Mikk tell you about what programming is like on a Monday :D.


So… I guess the main points I ended up making are: you shouldn’t write code on Mondays, everything is obsolete and programming is awesome (except when it’s not)!

If you want to know more of the harsh truth about programming and software, here are two articles I urge you to read: Everything is broken and Programming sucks.

I can see how this may sound a bit negative, but it’s not… really!

To make mistakes is human; to stumble is commonplace; to be able to laugh at yourself is maturity. (William Arthur Ward)

Get more stuff like this
in your inbox

Comments are closed.

Real Time Analytics