Hiring Programmers – the Good, the Bad, and the Ugly

I had a read through this A Guide to Hiring Programmers: The High Cost of Low Quality today, and found it very interesting. At a high level, I agree with the article, concerning the relative value of hiring the best, versus hiring whatever you can find. On the other hand, I have my own distinct opinions on this, and cannot resist sharing them 🙂

First off, despite the great content of the referenced post, the fact that it is buried in “Perl is the ultimate language” rhetoric is unfortunate. Whenever I hear anyone claim that any single language is the ultimate language, and that all enlightened programmers would use it if only they had the choice and the wisdom I get really worried (and frequently giggle). I am reminded of a statement I read once: “An idea is a dangerous thing when it is the only one you’ve got”. There is no such thing as a language which is perfect, let alone perfect for all applications and solutions. Over the last 25 years, I have programmed professionally using somewhere around 30 different programming languages. A fairly large number of those came with promises that they were the ultimate programming language. It was crap every time, and it still is. Give me a programmer with real world experience in many different languages (and many different domains if possible) every time. They have a higher probability of using the right tool for the right job, and can more easily learn new languages as needed.

Here are a few other comments I have on the hiring of programmers:

1. Always hire the Best. This is, unfortunately, somewhat ambiguous. What does “best” mean? Does it mean the same things in all contexts? just because someone was the star of their last team does not guarantee that they will work out on your team, on your project. Also, time plays a big part. Can you afford to spend a year finding the perfect person (see point 4, below)? 
2. Don’t hire programmers. Hire developers. While there are places on the team for hard core coding machines – people who live and breathe bits, people who can hold conversations in hex – I do not need a whole team of them. I need more rounded people (especially in a startup, where resources are tight and roles need to be flexible). I need people who can interact with users (i.e. paying customers), with marketing, with senior management, and who can understand the bigger picture beyond their debugger.
3. More Education <> Better programmers. Many of the worst programmers I have met had Computer Science degrees from great schools. Many had graduate degrees. Some of the best programmers I know have little to no university education in software development. When I am looking for good programmers, or better yet, exceptional programmers, I am looking first and foremost for thinking ability. I want people who have demonstrated problem-solving ability. I am looking for people who know how to learn, and know how to explore things which are new to them without getting scared. I would rather have a competent programmer who knows how to solve real problems than a genius programmer who is all theory.
4. You Can’t Always Get What You Want. Finding the people you need is never easy, and always risky. You always need them right now. You always need them to “hit the ground running”. Well, that’s not always the way it works out. You can spend a year trying to find just the right person, and after that year, you may still be searching. Sometimes it is better to find a smart person with the right raw materials (a smart new grad, or a smart person with a few years under their belt, but not the exact skills you want) and grow them into what you need. I have had a lot of success with this in the last 10 years.
5. Years <> Experience (necessarily). I have seen resumes come across my desk from people who had been working for 10 years, but did not have 10 years of experience. They had 1 year of experience, 10 times over. I have seen people who had been working for 3 years who DID have 10 years of experience (not really, but you get my point).
6. IT Analysts are not Product Developers. This is one I am shaky on, but I will throw it out there anyway. In my experience, most people who have spent their careers working in IT shops in big corporations have no hope of making as software developers in a product-oriented development team, especially not in a startup. There just seems to be some mental conditioning which makes it hard to do that transition.
7. Never underestimate the impact of a BAD developer. We have all hired them. People who for one reason or another do not work out in our team. Maybe they are idiots. Maybe they were burnt out on their last job. Maybe they are really good, but just do not fit in with the team or the project. Whatever the reason, never underestimate the impact they are having on your project. Their productivity will suck. Their presence will bring down the productivity of those around them. They can kill the morale of your team (which can be pretty fragile to begin with). Get rid of them. Take action sooner than later. If you think you can save them, take action in that direction, but set hard deadlines for improvement. If it comes down to it – get rid of them. Ultimately, you, your team, and probably the misfit employee, will all be happier for it.

I probably have more brilliant wisdom on this subject, but hey, it is midnight and I am supposed to be on vacation!

Oh – one last thing. The comment “It is the difference between Apple and Microsoft” is a mindless generalization, and is not worthy of the rest of the post. Microsoft has many groups of very talented developers turning out great code and great products. So does Apple. I would only say that Apple seems to have a distinct advantage in design – and I suspect that comes more from an all-pervasive culture than from hiring practices.