Spoilers:
How well you build on top of other people’s work.
A few years ago I was at Microsoft. Their performance reviews were based on what they called “three circles of impact”: your own output, how you support others, and how well you build on top of other people’s work. I hadn’t heard this way of thinking about it before. I liked it. The third one in particular stuck with me. It goes unnoticed and underrated.
What does that actually mean? As far as I understood it: Being able to read and understand code that’s written in a different style to how you’d write it. Not being limited by familiarity. Making changes that fit the theme and style of the code already there, rather than introducing your own distinctive flavour into someone else’s codebase. Minimal rewriting and refactoring - especially the kind that’s really driven by wanting to make things familiar rather than genuinely improving them.
I’ve worked with engineers who constantly complain about “readability” when what they really mean is they want the code to look the way they would have written it. Familiar equals readable to them. Unfamiliar equals unreadable. I’ve worked with engineers who can’t make simple changes without grand refactors, and then they break stuff. Engineers who can’t take work that’s been fleshed out and designed by someone else - they always need to be in the conversation from the beginning, or they’ll relitigate everything. Engineers who write code that looks and feels distinctly different to everything around it. To me, this is the real readability problem - not specifically how code is formed, but how consistent it is in form. Engineers who move onto a project and immediately declare that things are being done wrong, and there’s some other “proper” way to do it.
The bit about taking fleshed-out tickets might be controversial. Ideally, whoever’s going to implement something should be involved from as early as possible. But in an organisation, that isn’t always possible. It’s useful to have people who can take work that someone else has progressed and move it forward, rather than winding back and relitigating everything they don’t at first glance agree with.
The engineers who are good at this honour the decisions already made in the codebase. They can immediately move work forward, even if someone else has already started on it. They’re open to others’ ways of doing things. Humble about the fact that there’s a million ways to do anything, and their way isn’t necessarily best. Really, it’s the skill of saying “yes, and”.
I’ve seen it get overlooked. I think it’s worth giving it a shout out.
A note on how this post was written
Disclaimer: I hadn’t posted in this blog for many years mostly because I didn’t get round to it. I had ideas for blog posts, but didn’t find the time to write them out. For a while I also was doing technical blogging on the website for the company I worked for, so got my “technical writing fix” from that. Despite that, I’ve had years at a time where I didn’t write any technical blog, which I regret, as I think it is good for the mind and good for the soul. To kickstart me getting some of my thoughts down on paper again, I’m experimenting with using Claude code to assist me. I’ve tried developing a “skill” by getting it to process all my previous blog and all my writings in Slack to try to capture my “voice”. I’m giving it a stream of conciousness notes and asking it to write that into prose in my voice. So these posts are “written by AI”, but only with ideas I’ve told it to write, and hopefully in my voice. I’ll include at the bottom my raw notes that this article is derived from.
Raw notes this post was derived from: