Why the ‘Worst’ Programmer Was the Key to a High‑Performing Team

Measuring developer productivity can quickly reveal underperforming programmers. This piece discusses the worst programmer the author knows, Tim Mackinnon, and why he fought to keep him on the team.

Previously the author tweeted about the best programmer he knows; today the focus is on the opposite extreme—Tim’s dismal "productivity" data.

At a well‑known software consulting firm working for a large bank, the bank introduced personal performance metrics for assessment and development, which were translated into "completed story points" for the team. Managers avoided measuring lines of code or bugs to prevent cheating.

Using tools like Jira, each developer listed completed stories, generating convenient reports. Tim’s Jira, however, was perpetually zero—every week, every sprint.

The manager’s conclusion was clear: fire Tim and replace him with someone "who can get work done." The author refused without hesitation.

Tim never claimed stories. He spent his time pair‑programming with various teammates, patiently letting newcomers lead and using Socratic questioning to guide thinking, nurturing each moment of insight like a gardener.

When paired with senior engineers, he acted as a mental sharpening stone, producing solutions from diverse perspectives that outperformed solo efforts.

Tim didn’t directly deliver code; he forged a team capable of continuous delivery. His presence made the team more efficient, cohesive, disciplined, and the work environment more enjoyable.

The author invited the manager to observe: Tim always sat beside different teammates, helping refine requirements. Anything he touched saw quality rise and delivery speed increase—achieving quality, speed, and cost balance through discipline.

Eventually, the team kept Tim and quietly eliminated personal performance metrics, shifting to shared team responsibility and tracking (and celebrating) the real business value the team creates.

Key Takeaway

To measure productivity, target genuine business impact: dollars saved, revenue generated, risk avoided. If these are hard to quantify, proxy metrics are acceptable.

But never attempt to dissect individual contribution in complex systems—this approach is fundamentally flawed.

For example, DORA metrics assess the health of the technical delivery system, akin to checking overall engine performance rather than counting how many times a single piston rotates—such granular counting is meaningless.

If you ever have the chance to work with Tim Mackinnon, seize it. He isn’t writing code; he’s encoding a team’s DNA that continuously creates value.

References

[1] I Know the Best Programmer: https://twitter.com/tastapod/status/1010461873270153216?s=20