Continuing along with “The Two Things” advice theme, I’d like to address developer recruiting. As a reminder, “The Two Things” are the core tenets of a topic—all else is corollary.

For developer recruiting, I propose that those two tenets are:

1. Top developers are not looking for a job
2. The best way to attract developers is to make the job better

Of course, this applies to a lot of professions, but it especially applies to any profession (like programming) where the best are ten times as productive as the worst and two times as productive as the median (see Peopleware for the studies that back this up).

As I wrote before, if developers aren’t actively looking, you need to have a plan for recruiting passively looking developers. My main advice from that article was to fix your referral program. Your own employees are your best connection to great developers that aren’t doing an active search. For more on this, see Recruit Engineers in Less Time on Sequoia Capital’s founder-to-founder blog. One good tip from them: give a small token per referral rather than a big bonus on hire. This focuses the incentive on the process, not the outcome.

To see how hard it is to attract someone who isn’t looking, see this blog post by Jason Punyon, a StackOverflow Careers 2.0 developer, about an experiment they ran to see how effective it is to reach out to a random developer vs. a developer with a Careers 2.0 profile. The result: you were 6.5x more likely to get a response from someone that is at least considering a job-change. I’d love to see the break-down between active and passive (data that Careers 2.0 actually knows), but unfortunately, they didn’t do that analysis. My gut is that if your job-opening is genuinely a great opportunity, you have a good chance with a passive looker.

Which brings us to the second tenet. Knowing how to make a job better is not rocket science, but it requires internal change, which can be. Going back to Peopleware, Tom DeMarco recounted a story about a client that did an extensive internal study to find out what improvements their programmers thought would improve their productivity. They then decided to work hard on the second most requested item (team communication). When DeMarco asked why they didn’t work on the number one problem (environment and noise), the manager said, “That’s outside our control.”

I think everyone would agree that you should survey your programmers and find out how to improve productivity and job satisfaction. But, to really see change, you need to commit to fixing the most important problems, even if they are hard (perhaps, because they are hard).

To see how hard, turn to Thinking Fast and Slow, in which Daniel Kahneman reported that in his studies of workplace happiness he found that the driving factors of mood at work were coworkers, low noise, and absence of time-pressure. Peopleware reports similar findings for studies of programmers (especially noise and time-pressure). If you find this out about your organization, are you prepared to do what is necessary to improve it? Even knowing that it will come at considerable expense and organizational change? If not, surveying and then cherry-picking easy fixes way down the list might not have the effect you were hoping for.

There are many ways extreme job satisfaction will help with developer recruiting. For one, happy employees stay longer, reducing turnover and the need for recruiting. For new positions, you are much more likely to get referrals and benefit from “promoter behavior“, that only the very satisfied exhibit. Finally, top developers know a good job when they see it, and they can afford to be picky.