hiring badass programmers… or, at least… trying to

I’d love to say I know a good programmer when I see him (or her).  That would be a lie.  The difficulty in predicting the performance of programmers lies in the fact that programming, as human endeavors go, well… it’s a bit odd.  We’d like to say (as a group that wants to be taken seriously) that “programming is engineering.”  Well, in 2009, even our own beloved luminary Tom DeMarco admits:

“I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone.” — Tom DeMarco

Phew, I know I’m relieved.  Sure as shit, programming never did seem like engineering to me, the last 20 years I’ve been doing it.  Good thing we don’t have to carry on that charade.

We’re left with one other extreme view, that “programming is art.”  But I don’t think many folks want to see source code hanging in galleries.  Even the pinko commie FSF leader agrees, and he’s right because he’s an Emacs guy:

“I would describe programming as a craft, which is a kind of art, but not a fine art. Craft means making useful objects with perhaps decorative touches. Fine art means making things purely for their beauty.” –Richard Stallman

So, let’s split the difference and neatly pigeon-hole the practice of programming as a “craft”.  Seems fair enough.  Pete McBreen points in this direction in his book Software Craftsmanship.  Knuth was thinking along these lines back in 1974, too.  But using the analogy of “craft” doesn’t go very far to predicting programmer aptitude.  Unlike most other crafts (smithing, knitting, ceramics, architecture, furniture, you name it), programming exists in a realm of nearly pure abstraction, doused liberally with a tonic of interpersonal communication and collaboration.  An odd mix.

So how do you pick out the good geeks in a crowd?  Malcolm Gladwell writes about the difficulties, and I think there are strong parallels between finding good QBs, and finding good programmers.  Until you just try them out, you can’t really know.

Since I’ve long viewed the practice of programming as a craft, I’ve tried to apply the notion of a portfolio, a gimmick I learned from my boss back at AOL.  A good programmer should have a body of work, which can be shown, and in it you will find strong clues as to the type of programmer they are.  So unless I’ve worked with someone before, directly, along with references and resumes, I ask them to provide:

A significant code sample which you feel is representative of your best recent work.

You might be surprised how that surprises folks.  I’m not sure if they think I’m going to poach their code, or rat them out to the employers whom they were working for when they wrote it, or what.  In any case, of those that get over it and send me something, a disheartening number send me what amount to toys – 100 line incomplete snippets of something-or-other.  Or, just as bad, a swath of user interface callback code, or a class definition that’s 90% setters and getters.  Sigh.

Once I’ve settled on the notion that a particular person might be a good hire, I try them out.  That amounts to a six-month “no fault divorce” period, where the candidate is brought on board as a 1099 contractor, but in all other ways as a full fledged member of the team.  Most folks need six months to settle in, get embedded in team dynamics, and learn enough of the problem domain to be useful.  During that time, if anything doesn’t feel right – and I do this purely based on gut instincts – I gently end the relationship.

It doesn’t always work, but it works well enough.  Sometimes it makes me wish that there were true apprenticeships in programming, Programming Guilds whose members (graduates) would come as known quantities, merely through the imprimatur of their Guild Master.  Meantime, we do what we can.