One thing that seems to be a perennial favorite on Hacker News is discussion of the characteristics of a good programmer. Inevitably, people disagree on this subject. I think this is a difficult question to answer not because it’s difficult to recognize good programmers, but because it’s the wrong question.
Human talent cannot be reduced to a simple boolean proposition. People have different talents in different areas. People often have problems recognizing good programmers because they try to fit people into a box. They try to say that good programmers have characteristics x, y, and z, but that characteristics a, b, and c are never qualities of good programmers.
It turns out that for every good programmer you do recognize, there are probably several other people you wouldn’t have guessed in a million years would be any good. So here’s my attempt to help people understand good programmers better. Oftentimes, good programmers will fall under more than one or even all of these categories. But usually, they’re most talented in one area.
I should also point out that I’m probably just scratching the surface here. There are probably more types of good programmer than this.
The machine is probably the first person you think of when the words “good programmer” hit your ear. The machine is someone who has the job you asked for finished yesterday. Sometimes the most challenging task is simply finding things for them to do.
Machines are the easiest to recognize simply because their talent is more measurable: they get their tasks done way ahead of schedule. However, they’re not without their tragic flaws. Although machines are good at writing code, they rarely see code as anything but a means to an end. Left unchecked, machines can turn your code into a steaming pile of crap. Fortunately, that’s where the other types of good programmers come in.
The method man (or woman)
The method man is the one who brings discipline to the team. Their greatest strength is attention to detail. Usually, they’re the ones to poke holes in the architects’ brilliant ideas or to get the machine to slow down, take a breath, and think before coding.
It’s a bit more difficult to recognize a method man than it is a machine. The key thing to watch for is process. They’re the ones who describe everything they do in excruciating detail. This is also their Achilles heel. They’re good at applying rules and processes, but they freeze the instant they are faced with a situation that falls outside them.
The architect is the crazy guy (or gal) who rambles on and on about design patterns. Get him involved in a conversation and he’ll be delighted to tell you his latest theory about whatever random thing he’s thinking about at the time. While their ideas may come off as crazy, there is almost always a method to their madness.
They’re the people who make sure machines don’t have to care about their code. They’re also the ones to offer guidance to the method men when the rules don’t apply. They’re the ones who look out for the big picture while everyone else is distracted by details.
The hallmark of the architect is inconsistency. They’re the ones you come to when you have a really difficult problem. But assign them the most mundane task and a two-hour project just turned into a two-day project. Ask them to explain Goedel’s Incompleteness theorem, and you’ll get the most brilliant description you’ve ever heard. Ask them what a database is and you’ll probably get the most obtuse and technically dense answer you’ve ever heard.
So what other types of brilliant programmers have you come across?