The Worst Programmer I Know

The great thing about measuring developer productivity is that you can quickly identify the bad programmers. I want to tell you about the worst programmer I know, and why I fought to keep him in the team.

A few years ago I wrote a Twitter/X thread about the best programmer I know, which I should write up as a blog post. It seems only fair to tell you about the worst one too. His name is Tim Mackinnon and I want you to know how measurably unproductive he is.

We were working for a well-known software consultancy at a Big Bank that decided to introduce individual performance metrics, “for appraisal and personal development purposes”. This was cascaded through the organisation, and landed in our team in terms of story points delivered. This was after some considered discussion from the department manager, who knew you shouldn’t measure things like lines of code or bugs found, because people can easily game these.

Instead we would measure stories delivered, or it may have been story points (it turns out it doesn’t matter), because these represented business value. We were using something like Jira, and people would put their name against stories, which made it super easy to generate these productivity metrics.

Which brings me to Tim. Tim’s score was consistently zero. Zero! Not just low, or trending downwards, but literally zero. Week after week, iteration after iteration. Zero points for Tim.

Well Tim clearly had to go. This was the manager’s conclusion, and he asked me to make the necessary arrangements to have Tim removed and replaced by someone who actually delivered, you know, stories.

And I flatly refused. It wasn’t even a hard decision for me, I just said no.

You see, the reason that Tim’s productivity score was zero, was that he never signed up for any stories. Instead he would spend his day pairing with different teammates. With less experienced developers he would patiently let them drive whilst nudging them towards a solution. He would not crowd them or railroad them, but let them take the time to learn whilst carefully crafting moments of insight and learning, often as Socratic questions, what ifs, how elses.

With seniors it was more like co-creating or sparring; bringing different worldviews to bear on a problem, to produce something better than either of us would have thought of on our own. Tim is a heck of a programmer, and you always learn something pairing with him.

Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team.

I explained all this to the manager and invited him to come by and observe us working from time to time. Whenever he popped by, he would see Tim sitting with someone different, working on “their” thing, and you could be sure that the quality of that thing would be significantly better, and the time to value significantly lower—yes, you can have better and faster and cheaper, it just takes discipline—than when Tim wasn’t pairing with people.

In the end we kept Tim, and we quietly dropped the individual productivity metrics in favour of team accountability, where we tracked—and celebrated—the business impact we were delivering to the organisation as a high-performing unit.

tl;dr ¶

Measure productivity by all means—I’m all for accountability—ideally as tangible business impact expressed in dollars saved, generated, or protected. This is usually hard, so proxy business metrics are fine too.

Just don’t try to measure the individual contribution of a unit in a complex adaptive system, because the premise of the question is flawed.

DORA metrics, for example, are about how the system of work works, whether as Westrum culture indicators or flow of technical change into production. They measure the engine, not the contribution of individual pistons, because that makes no sense.

Also, if you ever get the chance to work with Tim Mackinnon, you should do that.