UPDATE: (This article on being action oriented in startups mentions its better to hire a lot (recognizing and letting the bad ones go quickly) than to analyze carefully and only choose the good. On the face of it, this seems to be counter what I'm saying here. However, the reason why hiring those talented, but motivated primarily by their desire to see their tech vision realized (rather than your business plan) is that it is really hard for non-technical people to recognize such people as bad hires until they've failed to deliver on the plan. They'll seem like they're really doing good. They'll tell you all about the great plan, and how it uses the best solutions that [insert hot tech company here] used to win, and so forth -- you just won't see your plan move forward while they find the best way to integrate cool scripting language du-jour into their system. The solution is in the article: force them to deliver results quickly and fail fast. The truly good ones will welcome the iterative nature of your business plan, the others will fight against such accountability. Boot them.)

A recent tweet led me to this article by Daniel Tenner from a couple of years ago. It outlines some things people (particularly non-technical people) should look for in order to hire really good programmers.

I think the list is dangerously misleading, because the items in question while possibly* necessary are definitely not sufficient. Worse, a non-technical person who follows this list - and chooses the wrong person - will hire someone who, not only will fail to deliver value to the project or company, but also someone with the capacity to do the endeavour massive harm; far more damage than what an average, or even poor programmer could cause.

Why? Because the list may enable one to identify smart technology enthusiasts, but it will not help with finding someone who delivers great results. To get that, you need someone who won't put gratifying their ego ahead of team and business goals - and unfortunately the list Daniel provides not only describes good programmers who deliver results, but also smart, self-centered egotistical ones too.

To summarize the list Daniel feels that "good" programmers are ones who are smart, passionate about technology, love to program and learn on their own, would (and have) done so outside of work, are knowledgeable about many disparate technologies and uncomfortable using technology he/she does not feel to be "right."

See the problem? What's missing: Will care if your project succeeds. What's present: Does this for his own ends. So what happens when the business plan calls for the "wrong" solution (e.g. because the "right" will take too long, a common problem in start ups - particularly when a less-than-optimal solution was proposed early on and will take too long to change). Without the humility and emotional maturity to compromise his perfect vision the good programmer that Daniel describes might well decide that the business plan is less important than his design vision - and wreck a project that was only somewhat sub-optimal.

To be fair, Daniel is replying to this article by Paul Graham and is attempting to distill his experience with finding good programmers. Paul has his own agenda (as Giles Bowkett points out** here) but both are trying to answer the question: How does a business person find good programmers. In this case, I think Paul's closer to the answer (he feels they can't). Daniel's list seems obvious to him (and to me) - but then we are both programmers. Daniel's answer to this is that he has been on the business side too. So have I - I've managed technical and non-technical projects and people (both well and poorly) and in doing so, I learned an important lesson: Non-technical people not only don't understand the difference between say Java and C#, they don't even understand whether they are comparable - and more importantly they don't care! What they want is someone to implement their business plan. They often want the best (or think they do, which is the same thing for our purposes now), but they assume that best means "best at implementing the plan" - Daniel's list will give them "the best at using the technology." That disconnect carries in it a huge risk; one bigger than hiring mediocre programmers: Because they are smart and so good at using technolgy these guys can and will greatly influence the course of the effort. If they are more interested in feeding their technology passion than implementing your business plan, they are in a position to drive your effort off a cliff, like no mediocre, passionless programmer ever could.

So the programmers business people really want are those really good at shipping technological solutions that implement business plans. How do you find those guys?

In my opinion, there's only two ways to find such talent: Know them already or get lucky. And there is only one reliable way to know them: You or someone you trust needs to have seen them succeed (in business terms) and they need to do it a lot - I'd say at least 90% of the time. You know one of these guys? Hire them - and their network of colleagues, now. Complement them with some junior programmers that know how to learn and want to (i.e. Daniel's list is much less risky for junior programmers, but you're better off finding those that have a track-record of shipping and let them hire the junior programmers).

If you don't know one, you're going to have to roll the dice. But you can still reduce your risk somewhat. And yes, Daniel's list will help you narrow the field. But you still need a sense if they'll care about your business plan. To do that add the following to your interview of Daniel's ideal candidate - it still won't be a sure thing, but it should help: Ask them how their projects went. Did the project ship? How late? How much money did it make? If they were part of a start-up, ask them how it did. If it failed, why did it fail? Then, listen carefully to their answers. If they don't seem interested in such questions, its a red flag. If they only talk about technology its a red-flag. Either way, they are likely to say they built (or intended to build) the ultimate solution. The ones you want to remove from consideration will tell you how all the 'others' got in the way. How management blew the opportunity, how the stupid (they might not use that word, but don't be surprised if they do) programmers who got there before them made all the wrong choices. If they shipped it will have been only because they were able to silence the nay-sayers and take control. The ones you want will mostly have found a way to ship anyway. They'll be focused less on how the others got in their way, and more on how they stayed focused on the business goal and made it a success. The ones you don't want will tell you about how others (almost) ruined it. You may even hear how they finally outmanuevered them and got hold of the reins - but ultimately the stupidity of others will be why he couldn't pull it out and so the product/project/start-up didn't make it. The ones you want will tell you how those things are just a part of shipping software and how the team/company/business (not just them!) found a way to win anyway.

In short: Daniel's list will point you at the technologically talented, but be sure to establish that they also care about your business' success, the risk if they don't is much too high.

*I say possibly because I am increasingly of the opinion that when programmers say "good programmer" it means "someone like me." For the record, I agree with Daniel's list - but then I started out on the Commodore 64, will talk endlessly about coding, make a habit of learning about anything and everthing and so on - i.e. that Daniel and I have a similar list may well be because we have a similar background and not because we know anything about being a good programmer.

**I find this post by Giles very uncomfortably true. Which means, you should be looking for my personal agenda in this blog entry, and not for any truth. I'd like to dub this Giles' Rake - because it's easier to see the point in Giles' blog entry than by reading the 700 or so pages of Stephenson's Anathem to get the reference to Diax's Rake