An Underrated Engineering Skill

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:

spoilers, i think it's: how well you build ontop of other people's work.

I was at MSFT a few years ago.
their perf reviews based on "3 circles of impact"
- your output
- how you support others
- how well you build ontop of other people's work

i'd not heard this way of thinking about it before.

i liked it.

the 3rd of these I think goes unnoticed and underated.

fleshing out what that means:
- being able to read and understand code that's writting in a different
  way. not being limited by familiarity.
- making changes fit the theme and style of code already there.
- minimal rewriting and refactoring which is really driven by making
  things familiar.

I've worked with engineers who:
- constantly compain about "readability" when really they want the code
  to look the way they would have written it so it's familiar.
- can't make simple changes without grand refactors, and then break stuff.
- can't take work / tickets that have been fleshed out and designed by
  someone else, always needing to be in the conversation from the beginning.
- write code that looks and feels distinctly different to all the code around it.
  this imo is the real "readability", how consistent something is in form,
  not specifically how it is formed.
- move onto a project and immediately say things are being done wrong, and
  there's some other "proper" way to do it.

point about taking fleshed out tickets might be controvercial. ideally
who's going to implement is involved from as early as possible.  but in an
organisation that isn't always possible and it's useful to have folks who
can take some work someone else has progressed and move it forward rather
than winding back and relitigating everything they don't at first glanec
agree with.

good having engineer who can:
- honour the decisions already made in the codebase
- immediately move work forward even if there's already been work done on
  something
- and generally being open to others' way of doing things and humble 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, and I think it's worth giving it a shout out.