All of which are part of the tiresome and long-running rock-star programmer debate, but it did give me pause for thought about the kinds of programmers I’ve worked with over the years and the categories I’ve started to (no doubt unfairly) group them into.

DISCLAIMER: If you’re a former or current colleague of mine the rest of the article is not about you. It’s about other people. You are a unique sunbeam that cannot be so cavalierly stereotyped.

The Categories:

1) The Truly Useless

These are the people that cannot be trusted to do anything right. They have somehow graduated without learning to program at all. They need constant guidance and handholding and generate negative productivity by sucking time from other people.

They seem to survive by either

a) Finding a company with poor hiring practices that lacks the nerve to fire them, or

b) Endlessly taking 3-month contracts (which are never renewed).

Sometimes these folks are just in the wrong job. In one case a former programmer eventually let go went on to thrive as a testing and QA specialist.

These people are why you need a decent programming test as part of the interview process. A programming test won’t distinguish the great from the good but it will filter out the Truly Useless.

2) The Toilers

These are the people that can get stuff done and do it well within their areas of expertise but will generally have trouble with

Doing significant design work.

Finding a solution to a problem that involves doing something architecturally different (realising that replacing a slow RDBMS solution with a persistent in-memory hash table might be a good idea for example).

Learning something new (like a scripting language).

Taking initiative to suggest and implement significant changes.

There seem to be a couple of different kinds of toiler.

The JobsWorth: Some people just want their job to be as easy as possible. They don’t want the hassle of doing anything extra or agitating for change. They just want to put in their hours and get paid. I think some people are afraid of responsibility, too.

The Struggler: They can do it, but it’s hard work. The code gets done but they spend days baffled by mysterious bugs. Everyone’s a struggler at some point, I certainly was. As I get older I’ve realised I’m not necessarily smarter than a new graduate, I just get more done because I can fix that bug they spent 2 days on in five minutes because I’ve seen it before (3 years ago, in fact, when I spent 3 days fixing it).

3) The Go-To Programmer

This is Joel’s Smart and Gets Things Done programmer. My definition is: this is the person you can trust to solve a hard problem; the programmer with the smarts, experience and imagination to get around most of the problems encountered in a software project without handholding. This programmer will, for example:

Trace a bug into another subsystem in an unfamiliar language to fix it rather than saying “that’s the Java programmer’s problem”

Realise that there’s a big ‘ol lump of work between “code complete” and “software is released” that need to be planned for.

Be proactive about overcoming roadblocks rather than halting and waiting for guidance.

Not act like the team leader is the only person allowed to do design.

Come up with the complex load-balancing architecture that saves your website.

Ideally, your whole team (and you) is this sort of programmer. Go-To programmers are like gold to a PM or team leader because you can trust them to get things done and not bollocks them up.