Chris’ Corner: Doing a Good Job

This is a great story from Dan North about “The Worst Programmer I know”, Tim MacKinnon. It’s a story about measuring developer performance with metrics:

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.

Scared? Maybe you can guess. Tim was very bad at metrics.

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.

Why? Maybe you can guess again. Tim wasn’t playing that game, he was a true senior developer in the sense that he nurtured his team.

… 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

Tim wasn’t delivering software; Tim was delivering a team that was delivering software.

Every organization is different though. Mercifully in the situation above, Dan protected Tim. But we can all imagine a situation where Tim was fired because of this silly measurement system. (That always reminds me of Cathy O’Neils Weapons of Math Destruction). Getting to know how the organization works, so you can work within it, is another approach that Cindy Sridharan advocates for. See: How to become a more effective engineer.

You can either complain and pontificate on Twitter on how the tech industry *should* ideally work, or you can learn how your org *really* works and what’s rewarded, and optimize for that.

Different organizations will have different paths to these answers. I’ll pluck off a few bullet points:

• exactly what technical skill you need to invest effort into getting better at, which will actually be rewarded
• how to build lasting relationships with other people on your team or organization that ultimately dictate the success of a project
• how to effectively pitch projects or improvements to leadership and actually see these through to completion
• how to weigh the pros and cons of technical choices in the larger context of the organizational realities and needs
• how to discern what’s achievable, and in precisely what time frame

Figure out who matters, what they care about, and how to effectively get things done. And don’t wait!

To build credibility, you need to demonstrate some impact early on, instead of waiting months to get the lie of the land before you start getting anything done. Chasing small wins and low-hanging fruit can be an easy path to productivity. Don’t underestimate their importance.

Another one I like in this realm of being a truly effective developer is Artem Zakirullin’s Cognitive load is what matters. A good developer can write code that themselves and others can read without being so complex that, well, you run out of mental capacity.

When reading code, you put things like values of variables, control flow logic and call sequences into your head. The average person can hold roughly four such chunks in working memory. Once the cognitive load reaches this threshold, it becomes much harder to understand things.

That tracks for me. I start tracing how code works, and I’m all good and have it in my head, then it feels like right at the fifth logical jump, my brain just dumps it all out and I’m lost.

I suspect it’s a talent of really great programmers that they can hold a bit more in their head, but it’s not smart to assume that of your fellow developers. And remember that even the very smart appreciate things that are very simple and clear, perhaps especially.

You know what strikes me as a smart developer move? When they work together even across organizations. It’s impressive to me to see Standard Schema an effort by all the people who work on any library that deals with JavaScript/TypeScript schemas to make them easier to use and implement.

The goal is to make it easier for ecosystem tools to accept user-defined type validators, without needing to write custom logic or adapters for each supported library. And since Standard Schema is a specification, they can do so with no additional runtime dependencies. Integrate once, validate anywhere.

There are heaps of libraries and tools that already support it, so I’d call that a big success. I see Zod released Mini recently, which uses functions instead of methods, making it tree-shakable, but otherwise works exactly the same. Likely a nod to Validbot which was always the “Zod but smaller” choice.

Another thing I think is smart: seeing what developers are already doing and making that thing better. Like, I’m sure there are very fancy exotic ways to debug JavaScript in powerful ways. But we all know most of us just console.log() stuff. So I like how Microsoft is like, let’s just make that better with console.context(). This allows for better filtering and styling of messages and such, which would surely be welcome. Might as well steal formatting strings from Node as well.