Paradox of the miserable programmer

What I call “the miserable programmer paradox” states the following:
“A good programmer will spend most of his time doing work that he hates, using tools and technologies that he also hates.”
This is a paradox in the sense that it’s a counterintuitive result; you’d expect that the bad programmers would spend their time with crappy technologies, while the excellent programmers would spend their time with super-awesome technologies. Right?
I noticed this paradox in practice, and only later did I realize why this is happening.

What kind of work does a programmer despise?

This will not be news to experienced programmers, but I want to explain this to people who are not programmers:
A good programmer despises doing any work that could be automated. If a programmer is made to do work that a machine (usually a computer) can do, he becomes very annoyed. A programmer’s aspiration is to teach the machine to do as much of his job as possible so that he’ll have to do only the bits of work that cannot be done by the machine.
This is a very healthy instinct for a programmer to have.
Simple example of work that needs to be automated: Imagine the programmer is browsing his code file which is 1000 lines long. He wants to get to line 791 because there’s supposed to be a bug there that he needs to fix. But his text editor is at line 30. Most human beings would simply scroll down the file until they pinpoint the wanted line. But a good programmer will not stand something like this. He will work in an editor which lets him jump to a specified line by number. For example, “Ctrl-L -> 791 -> Enter” will do the job in the editor I use.
That was a simple example; there are more complex ones.
The reason that a good programmer hates doing repetitive work is that all these little tasks interrupt the programmer’s train of thought. A train of thought is a fragile thing; Once your train of thought is interrupted, it takes a while to get it started again. If you have to interrupt it every 5 minutes to do some manual task, then your train of thought won’t get anywhere.
In his day-to-day work, a programmer needs to do various kinds of work with various technologies using various tools. The programmer enjoys the kind of work that has relatively little “manual labor” in it, and he despises the work that has a lot of manual labor to it. He loves the technologies and tools that require little manual labor (Python, Django and git would be a few of my examples), and hates the technologies that require a lot of manual labor. (I won’t give examples on that one :)
But he still has to work with both the fun automatic technologies and the annoying, manual-labor-requiring technologies. The good programmer tries to cut as many bad technologies as possible out of his life, but he will always have some bad technologies that he simply can’t get away from. Sometimes it’s because they’re needed for the kind of software that he wants to produce; for example, every programmer working in web has to deal with HTML and its many annoying behaviors. Sometimes bad technologies are necessary simply because the masses of people are still using them, and the programmer needs to be able to work together with them.

Most of the time is spent on the bad technologies

From this point, understanding why the paradox happens is quite straightforward. The bad technologies take big chunks of time and concentration. The good technologies take little time and concentration. The programmer has a fixed amount of time and concentration that he can give every day. He must give a bigger piece of the pie to the bad technologies, simply because they require more. In other words, he ends up spending most of his days working with tools and technologies that he hates. Therefore, the good programmer is made miserable.
I wish I could end this essay with some sort of moral, or an idea for solving this problem, but there’s not much. All we can do is try to cut as many bad technologies as possible out of our lives, and just tolerate the rest.
(Thanks to Imri Goldberg, Amit Aronovitch and Amir Rachum for helpful feedback when writing this essay.)


No comments: