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.

Advertisements
About

I have been working in the world of technology for 25-odd years. I am an entrepreneur and consultant, focused on software solutions, social networking, and innovation processes. Currently, I am a Principal Consultant with T4G Limited, specializing in Portal Technologies (including SharePoint), software/systems development, service oriented architectures, and many other things which I will probably not remember until I need to use them. Prior to that, I was VP of Technology at Whitehill Technologies, Inc., where I spent almost 9 years helping to grow the company from a start-up to one of the most successful private software companies in Canada. Prior to that I worked on internet conferencing using early VoIP, and on large military communications projects. Before even that, I worked in satellite control, and remote sensing. Going way back to university, my focus was on theoretical physics and astrophysics. Currently my interests revolve around most aspects of software development, from technologies to management, and in the area of defining sustainable, repeatable processes for innovation within technology organizations. I also have a particular interest in Tablet PC technologies – I have been using one for several years, and I love it. On the personal side, I still have a strong interest in all aspects of science, especially physical sciences, as well as philosophy and comparative religion. In addition, I am into music, playing guitar (badly, I am sorry to say), and reading almost anything I can lay my hands on. I am also a member of the IEEE/IEEE Computer Society, and of the Association for Computing Machinery.

Tagged with: , , , , , ,
Posted in People
One comment on “Hiring Programmers – the Good, the Bad, and the Ugly
  1. […] the developers who fit your profile, that is a luxury most of us do not have (see my previous post on hiring). The reality is that you are almost always going to have a distribution of talents on your team – […]

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Obligatory Disclaimer
Please keep in mind that any opinions, points-of-view, comments, or other content which I post to this site are mine and mine alone. They in no way reflect the views of my employer, my country, my dog, my cat, or anyone else you can think of. To paraphrase Monty Python, "That is the theory that I have and which is mine, and what it is, too."

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 623 other followers

%d bloggers like this: