The worst programmer I know
The good thing about developer productivity is that you can quickly identify bad programmers. I want to tell you about the worst programmer I know and why I fought to keep him on the team.
A few years ago I wrote a note on Twitter/X about the best programmer I know, it should be rewritten as a blog post. I think it’s only fair that I talk about the worst. His name is Tim McKinnon. I want the world to know how much he is measurably unproductive.
We worked in a well-known software consulting company for Velikiy Bank, which decided to introduce personal performance metrics “for the purpose of analysis and personal improvement.” The system spread throughout the organization, and reached our team as an indicator of realized story points. This came after a thoughtful discussion with the department manager, who knew we shouldn’t be measuring metrics like lines of code and the number of bugs found, because people can falsify them.
Instead, we should have measured the number of stories realized, or it could have been storypoints (turns out it didn’t matter) because they represented business value. We used something like Jira where people had to put their name against the story, so it was very easy for us to generate these performance metrics.
And that brings us back to Tim. Tim’s score was always zero. Zero! It wasn’t just low and didn’t tend down, it was literally zero. Week after week, iteration after iteration, Tim got zero points.
It was obvious that Tim had to be fired. The manager came to this conclusion, and he asked to make the necessary preparations to fire Tim and replace him with someone who could fulfill the story.
Without further ado, I refused. It wasn’t even a hard decision for me, I just said no.
In fact, the reason for Tim’s performance score of zero was that he was never recorded in any stories. Instead, he spent his day interacting with various team members. When working with less experienced developers, he patiently let them take the lead while pushing them to the right decision. He did not rush or push them, but gave them time to learn, carefully preparing them for moments of enlightenment and gaining experience, often with the help of Socratic dialogue: “what if we do this? how else can it be done?”.
His interaction with the seniors resembled co-creation and sparring: they brought together different views of the world to solve a problem, to create something of higher quality than each of us could come up with individually. Tim is a great programmer and you always learn something new when working with him.
Tim didn’t build the software; Tim was building a team that was building software. The whole team as a whole became more efficient, more productive, coherent, idiomatic and interestingbecause Tim was in it.
I explained this to the manager and invited him to come and observe our work from time to time. Every time he came in, he would see Tim talking to someone new working on “his” task, and you could be sure that the quality of the solution to that task would be significantly higher and the implementation time significantly lower – yes, you can do it at the same time better, faster, and cheaper, it just takes discipline—than when Tim didn’t interact with people.
Ultimately, we kept Tim on the team and quietly abandoned individual performance metrics in favor of team-wide reporting when it comes to tracking the business value we deliver across the organization as a single, high-performing unit.
tl;dr
Measure performance in any way you like (I’m all for reporting); ideally, this should be a measure of business benefit, expressed in terms of money saved or earned, as well as reduced costs. It is usually difficult to determine, so you can use auxiliary metrics.
Just don’t try to measure the individual contribution of a unit to a complex adaptive system, because the very formulation of the question is wrong.
For example, DORA metrics are related to how the work system is performing, whether it’s Westram’s culture indicators or the flow of technical changes in production. They measure the performance of the engine, not the contribution of individual pistons, because that doesn’t make any sense.
Also, if you get a chance to work with Tim McKinnon, do it.