The recruitment process for developers

Sunday, December 16th, 2007 at 01:18pm

Last night I finished reading through Joel Spolsky’s book on recruiting developers, Smart and Gets Things Done.

This was a bad move as I started thinking back over my involvement in the recruitment process at work, seeing what rang true and what didn’t. In itself this was good. What was bad was that it prevented me from getting to sleep.

The most useful thing about the book (and in his articles where I had already read much of what is in the book, but had forgotten) is that Joel is not afraid to state the truths that many seem reluctant to acknowledge. For example:

  • Not all developers are created equal and they are far from interchangeable; and
  • It is better to say no and live with a vacancy than to fill it with someone who has no positive effect on the team.

The final chapter is not really about recruiting new developers, it is about fixing an existing team. To be honest this chapter alone is much more relevant to me than the six repceeding chapters.

I picked up two main points from this chapter:

  • Get rid of the underperformers that are wasting the resources of the team; and
  • Provide sufficient information that enables people to identify with the goal so they will want to perform the task, the Identity Management Method.

(I acknowledge that I am guilty of using for the Command and Control Management Method.)

In my experience there are two reasons why getting buyin from the developers fails:

  • Management actually considers the developers to be all the same so they don’t need to know the goal, they can just churn out the code; or
  • There is no actual business goal to buy into. At most the goal is something like ‘so and so said to do it’. That is no goal.

This time of year is full of tasks with arbitrary deadlines which, to me, fall into the category of not having a business goal. Why should we compromise on a solution to get it done by the end of the year? Will the stakeholders even look at it over the christmas/new year break? Will they even look at it before the end of January?

Getting it done by the end of the year just so a manager can tick a box is always a waste of effort. Either more effort will be spend in January fixing the problems introduced by the compromises that where made, or the problems will never get fixed which causes even more problems in the long run.

Enough of this rant.

This book is now on my list of books to get (I only borrowed the copy I read) and it has also given me another prompt to re-read Mythical Man Month and Peopleware.

Tagged with: , , , ,