This started off as a blog-comment to this article, but then grew large enough to merit its own post.

These “this makes a good programmer” articles are very simplistic. If you’re writing code that will “live” a long time, and will be worked on by many programmeres long after you have left, then it’s no good ‘having the chops to bang out killer features’ if the code you end up with is unmaintainable. Conversely, if you are working on a codebase for, say, an arcade game then the ability to carefully analyse, document, implement and debug your code will count for nothing if it’s not fast enough.

I like to imagine the difference between John Carmack and the guys who write the Shuttle code for NASA (Nasa article here, read ‘Masters of Doom’ for an overview of Carmack). For Carmack, the ability to implement features that almost nobody else could even think of was/is his trademark. And the ability to implement them faster than anyone else was his golden ticket to fame and fortune. However, Carmack essentially threw away his code at the end of each game and started again. For the NASA guys, the code they write absolutely definitely has to work 100% all of the time, without exception. They spend huge amounts of time, and money, trying to ensure that no bugs slip into the final release. They will chase those bugs down to the detriment of speed, of “sexiness”, of “that’s a cool idea”, of “well I think my way of doing it is better”. They produce the 99.99% bug-free software, the type that Carmack doesn’t aim for. Carmack produces the 99.99% performance software, that the NASA guys don’t aim for.

Despite these completely different approaches, is anyone going to argue that Carmack is not a good programmer? Is anyone going to argue that the NASA guys (and girls) are not good programmers? No, but we can argue that “programmer” as a catch-all term is too imprecise. What makes one “programmer” good in one context does not necessarily make them good in a different context.