There is a discussion brewing on HN today about measuring programmer productivity. Reg Braithwaite chimes in to ask a very pertinent question:
Programmers talk about productivity all the time. They say they’re more productive with static typing or without it. With Ruby or with Java. … It seems every programmer I meet has strong opinions about when they are more productive and when they are not. So, here’s my question:
How are all these people measuring programmer productivity?
The observation is spot-on. Most developers know exactly what makes them more, or, less productive. They may not be able to assess if something they haven’t used yet will boost their productivity; but of the tools and habits they have tried in the past, they have strong feelings about their current choice.
In an intangible way, every good developer I’ve met knows when she has had a productive day. It’s mostly a feeling that comes without rational explanation. This intuition is what developers are using when they express their choice for Java or Ruby. They have used both, and they know which felt right and which did not.
But there is a catch: you can’t harness this intuition if there are incentives to assess your own productivity too positively. Say, like, an annual performance review that your job depends on. Yet, this isn’t because developers are crooks. Something so intangible like an intuition is susceptible to being skewed for very innocent psychological reasons. This is also why a good manager will allow you to freely raise the issue when you haven’t been productive. It’s the only way she can find out why and address the root cause whatever it may be.
Professional assessment attaches very real consequences to being productive. You can’t let a developer search her own soul about if she should get a raise this year. She would really like to believe she should. However, if you simply want to make your team as productive as possible, let them be honest with you about it (and, by extension with themselves).
