Thursday, March 14, 2024

The Worst Programmer I Know#dannorth.net

This one hits me in the feels as I 100% agree with the point the author is trying to make.

Quoting a large chunk of the piece:

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.

I said to my colleague Ben at work that if I was an engineering manager I'd want to have someone who performed the role Tim does on my team. Essentially a "lead pair programmer" or something along those lines. Someone who knows the stack end to end and does a tonne of pairing. Pairing is essentially their entire job.