Adding The Most Value In Your Software Engineering Discussions

13 min readJan 12, 2022

This is *probably* not the best way to learn anything. Underlying image borrowed from Reddit.

Something I find myself talking a lot about recently is our contribution to value.

At the coarse grained level, this is basically, ‘am I doing my job well enough?’, and at my level perhaps more specifically, ‘what sort of work should a principal/staff engineer be doing?’. My peers and I regularly ask ourselves and each other that question, and it is well worth continuous reflection.

At a fine grained level, it becomes, ‘what’s the most valuable contribution I can make in this moment?’

Whether it’s big role questions, or how to behave in an individual interaction, we so often find it to be a matter of layers.

Having recognised this, more and more I find myself taking part in or observing discussions about engineering where I look at how the effort is being expended, and I sometimes feel like it’s not the best use of our time. Here, my input tends to become focused on trying to elevate people’s behaviours towards higher layers of value.

What do I mean by this?

A Common Context: Pull Requests

We all operate in different contexts and environments such that talking about our experiences in detail is not always wholly transferable, but we do have some ubiquitous ceremonies and interactions. One of these is the pull request review, or ‘PR’.

This article uses PRs as a framing but it is certainly not limited to them. This is relevant to all your interactions.

I’ll be honest: I don’t much like PRs, or at least, the ‘here’s a diff to read on your own’ flavour. I feel like it’s usually pretty hard to assess work on a line-by-line basis; the presentation of information lends itself to pedantry, certainly including my own, and the mechanics of the process lend themselves to unintentionally passive-aggressive interactions. However: I do accept that they can be the most effective way to get code through, so it’s no surprise that we tolerate them.

Especially in that context, though not confined to it, it’s psychologically easy to nit-pick at the detail; far harder to reason about big, holistic things and zoomed-out patterns. Our lizard brains love cheap decision making, so of course that’s what we go for by default.

The trouble with this is it’s often not valuable, and in many cases can be counter-productive. I spend a lot of time trying to nudge smart engineers into contributing value at a higher level — and I’ve sympathy for them in this, as I’m far from perfect at this myself either.

A savvy, experienced individual contributor said this to me recently:

Engineers write code, senior engineers get excited about the one true way to write code, [staff or] principals inject the pragmatism

In my anecdotal experience, there’s deep truth to this, although I would say there is no necessity to it. If you’re a senior, you’re not obliged to operate this way. This is mostly experience and behaviour, not role, remit and responsibility.

There’s nothing to stop you elevating the value you bring, and indeed it’s an essential part of your career development.

What’s Value Anyway? And An Illustrated Example

What does a high value contribution look like? A quick opinion:

high relevance in the ‘big picture’
high longevity
broad scope
propagation beyond the individual
people-centric

Some of this is pretty obvious: better to spend your time on things have positive repercussions across the landscape for a long time, of course.

But let’s invert it and think about low value, which is easy to lose sight of.

Suppose someone, let’s say a relatively junior engineer, presents you with a piece of code they’ve authored. Just to add an extra dimension, let’s say we’re working across team boundaries here, so you’re not super familiar with the author and you don’t have common direct management.

The code:

works, could be shipped
is not syntactically great
doesn’t conform to the standards and idioms you would use
is in some area that neither changes nor arises very often
is in a component that has relatively minor system relevance
was independently authored without much support

The engineer, perhaps unbeknown to you:

has some but not huge software engineering experience
is still learning how to write optimal, idiomatic code
is still learning how to behave, especially how to align and conform
has some imposter syndrome to contend with

Let’s contrive an example of this code. This is in Kotlin if you were wondering, not that it really matters. If bits of it weren’t imaginary, it should compile and run as intended.

Then let’s annotate this with everything we can find wrong here. You can have a go at this yourself if you like before reading further.

This could be a PR review submission. And if you weren’t very careful about how you do reviews in GitHub, it could manifest as a slowly rising tide of 15+ separate comment notification emails too.

These are individually reasonable and justifiable comments.

But if I was the author and I received this review, honestly? I would never want to go through this again. Consequences:

Remember how we’re working across team boundaries? I will be at the very least cautious about working with you & your team again
I will probably talk about that to other people
I will develop avoidant strategies like rolling-my-own over sharing
I might actually quit this place or even software dev, sooner or later

Was it worth it to get that spacing spot on?

Ignoring for now that we have somehow subtracted some value, let’s triage these comments:

almost no value: style and formatting pedantry, unjustifiable preferences
slight value: some general language advice that can be used in future
increased value: a fleeting hint at software characteristics like testability

There’s not really anything above this threshold here. We haven’t contributed anything in terms of:

expressing this ‘meta’ information of what actually matters most
helping the author understand why you’ve said all this
significant sustainable relevance in this — look again — temporary feature
looking after this person’s development
advancing our values and culture through empathetic practice

And we absolutely could have.

An Upside Down Pyramid Of Giving A Damn

I’ve seen enough of this recently that I’ve started to distil it into an increasingly solid mental model of layers of value, most of which relates to things we touched on above.

This is a heavily caveated model — hey, it’s not even a real pyramid— and it’s a work in progress. But let’s have a look at what I think so far.

When we consider our involvement in discussing something that is fundamentally workable (i.e. we are not talking about objective fault) but open to further scrutiny, I like to think about this set of layers.

What’s going on here? Let’s break this down.

‘Code Detail’ is mostly what we’ve been talking about above. Conformity is certainly helpful, holistically — it keeps things consistent and produces a shared, automatic adoption of good, whether people know why they’re doing it or not. But beyond whether it works, code is usually subjective. Other ideas are available. And you really need to be confident that it matters. Is this code that you’re so concerned about… well… ever going to be seen again before the heat death of the universe?

Also: your contributions here can be really easily replaced by a robot. I don’t think anyone wants to turn up to work to discover that their pass doesn’t work any more and a gleaming, beaming linter is sitting at what was their desk.

‘Code Consequences’ get a bit more interesting. For example: if you put some responsibility in the wrong place, you might well make your system unnecessarily brittle and thus you increase the cost of future change. If you can identify that, and we can avoid that, let’s avoid that. But: code is malleable, and this is probably not our last chance to get this right. It’s not fatal.

Side note: if this is coming up at PR review, we might be best moving these discussions to a more appropriate format, away from the detail, like an architectural decision record (ADR) or a request-for-comment (RFC) document.

‘Delivery Consequences’ — the nature of this depends what you actually do. In my current line of work, it’s mostly ‘audience value’; regularly getting something out to users, even if it’s not completely perfect. Shipping provides both direct benefit, and an opportunity to learn about our work. Delivery is also about sustainable quality, supporting rapidity of development, usability and a wide array of non-functional requirements.

We don’t always like to admit it but satisfying what our employer pays us to do is usually more important than engineering egos and absolutely perfecting the craft, not that good engineering and goal fulfilment need be mutually exclusive.

So, what is your interaction going to provide in these terms? On balance of probability, is it positive, like reducing a tangible post-deployment risk, or is it actually negative, holding up delivery?

Why, I hear you ask, is ‘delivery’ down here in the mere middle of the stack? Surely the overall delivery matters above our own goings-on? Maybe, but… now we get on to people, and how are you going to continuously deliver anything without people?

Learning and Development — I’ve labelled this as concerning the individual, since that’s where authoring discussions are usually directed, although sometimes we have the luxury of team education, be it through mobbing or just open discussion.

If you’re serious about wanting the devs around you to learn their way out of their dependency on you providing low-grade, syntactical guidance, you need to focus on the reasoning for why we do what we do. This ought to be illustrated by surfacing consequences and ideally having them experience some of it for themselves, rather than mere pointing and telling. You’re not going to arrive at this if your thinking is that people will iteratively navigate to doing something right through a long sequence of uninformative correction.

‘Individual Wellbeing’ — Education in the context as we have discussed it so far here is essentially a means to an end, that end being producing higher quality or reducing instances of something you prefer not to see. Even having achieved this, you can have a set of educated but deeply unhappy, frustrated engineers. Treating people well is key to unlocking value from — and propagation of — that education.

I suppose this (and education above) is kind of what Maslow was on about when he did his right-way-up, pointy-top pyramid.

In our PR example, we showed no real sympathy for or empathy with the author’s state of professional development, or really, them as a person. We weren’t outright mean, rude or even curt, but we didn’t express any basic human warmth either — that it’s OK that they don’t have this quite right, that we are more than willing to help them, that hey, we can convene to talk about this like normal people instead of playing endless, disconnected PR comment tennis.

An aside: occasionally — and not really in our teams — I get that sense that some engineers think they shouldn’t have to go out of their way to tread the sympathetic approach, because engineering correctness should speak for itself. I mostly disagree, but even if this were true, being sympathetic costs you very little, generates buy-in to your ideals, and makes you a more effective leader.

Then, finally, culture. Culture is the set of qualities in the last few levels but as manifested across whole teams or organisations. Help one person become a better fledgling developer in an empathetic way, and I will bet you that you can subsequently watch them adopt the same behaviours when working with and eventually leading others — and with time, this becomes replicated exponentially and normalised — ‘it’s just what people do here’. That’s massive value. Fail to do so and I’ll bet you an even greater sum that you can watch toxic interactions cascade out into cultural normalisation. And your people depart. Who wants to stay working in that environment?

Where Do I Begin With This?

Lovely, great, all good talk. But what’s it got to do with you, a single, individual engineer without enormous influence? Do you really command the power to change the team culture forever?

Yes you do.

Start with what you really tangibly own. Back to our PR review. How about this as an improvement?

What value have we added here?

Learning and development: we offered the author open opportunities for learning and improvement without demanding this as mandatory.
Wellbeing: we made some effort to structure our comments sympathetically and frame it in a low-pressure, empowering way
Culture: we took the opportunity to induce collaboration and knowledge sharing with two practical ways forward; engaging in this may be novel to this author. Plus our behaviour on the above may well influence others and that’s culture too.

This PR is approved at this point. You might be tempted to describe this selective filtering of issues as ‘picking our battles’, but it’s not a battle, it’s assistive collaboration.

This ‘review’ set of comments is still imperfect and at risk of ambiguity or misinterpretation — a good idea here would be to reach out, outside of the highly impersonal PR process, offer some assistance, and reassure them that when you say it’s optional, no really, it’s optional. That’s another wellbeing and culture contribution.

Also, so easily missed in our nerd-world obsession with detail: don’t forget to praise and reward them for both the delivery of this thing, and whatever growth and development you perceive they may have demonstrated here.

What Did We Just Concede?

Taking the above, what if, despite the opportunity for correction and improvement, they’re rushed, they decline or defer indefinitely, and they merge and ship these defects that you would have liked corrected?

Well, putting it politely…

Who cares?

Unless you find it becomes a regular and sustained pattern contrary to justifiable expectation of improvement, in which case you are already talking about intervening with a broader, higher level value contribution around education, honestly: who cares?

I know that there’s a really strong temptation to intervene. I know that not doing so can feel a lot like abrogation of responsibility. If not this, what? If not now, when?

But again: most code is malleable, and most code is imperfect. This isn’t your last chance to resolve anything. The code works and will ship OK. You offered your expertise, you encouraged some good behaviours, this minimally-relevant thing got unblocked and thus unblocked delivery of the wider piece to your users, you swerved a whole load of culture perils, and your engineers probably feel relatively good. And with that set of wins, you’ll no doubt get closer to what you seek on the next round of interaction. It’s OK — let it slide.

A Conclusion, With Caveats and Counterpoints

This is all conditional and contextual. You will be able to interject with countless yes buts and exception cases, and you’ll no doubt be right about some of them too. You can’t take any approach like this and just stamp it over everything.

On the other hand, there were elements in the example here — like the temporary feature or the junior developer — that weren’t essential to this recipe. You can do what we’ve been talking about regardless. It’s for you to find the right balance.

We’ve seemingly trashed the importance of detail in some of this, and it’s not entirely fair: detail does matter. The sum total of our details produces big, important outcomes, like maintainability, or whatever else you want to name. Don’t allow the pursuit of higher value to permit total surrender on the finer pieces.

This isn’t all-or-nothing, it’s more allocation and division of where you use your influence, authority and social credit balance. This is an approach concerned with thrust and spirit, not every single thing you say or write. Think of it more as a guide to take into consideration and influence your behaviours.

But detail as your only focus? We are standing waist-deep in a river of detail, constantly flowing down around us, in new development or change of old. Some of it will be washed away completely before long. You and your fellow curators of this detail have greater permanence, and you carry with you opportunity for future improvement. Letting some of it go by for now is OK.

The pay off here is long, too. You will require patience. If you had got that syntax fixed, you could have said ‘job done’, right there and then. Individual and teams’ professional development is far slower and harder to measure, and can take years to fully pay off. But it will pay off, and that dividend is a superpower, whilst all the detail you were initially compelled to argue the toss over has vanished into unremarkable history.

A More Convenient Diagram

I wanted to discuss this before I threw it into labels, but here’s an approximation of the above explanations in an annotated form in case it’s useful.

Comments, opinions and feedback welcome! This is certainly a journey rather than some fully formed and polished wisdom.