Elliot Morris

Most software engineer job descriptions will have a requirement like this :

Has the ability to deliver ticketed tasks promptly and to a high quality standard.

This is well and good, it’s the primary gameplay loop of software engineering afterall. Receive ticket, make changes to match the behavior described in the ticket, make sure your code is reasonably readable and documented, deploy code to main. Via this mechanism, you deliver value.

After a time, you gain confidence in this, your peers and managers will praise you for your ability to do these tasks mostly unaided. The product becomes malleable to you, you start to think there isn’t any task you can’t accomplish given enough time. Heck, maybe you could even rewrite the entire product.

Congratulations on beating the tutorial.

Most organizations would have already promoted you to senior engineer by this point. This is an industry-wide mistake. Whilst I won’t go so far to encourage folk to turn down promotions, I will encourage them to avoid conceptualizing themselves as experts before they are ready. The real journey has only just begun.

Being able to deliver any given feature somehow is table stakes. Up until this point, you have not been contributing very much to your organization, not really, in fact you’ve probably spent a significant part of your career being a net-negative contributor in terms of absolute product value. This may seem shocking, clearly you’ve been delivering features, probably some customers even find them useful, but this is missing the point.

All change has cost, and although the organization will assert that the value of ticket delivery is always worth the cost of change, (otherwise they wouldn’t have asked for the feature right?) the truth is more complicated.

Creating any one single behavior in a computer system is almost always trivial for the experienced engineer. When the experienced engineer on your team says that something can’t be done easily, they almost always mean is that the thing can’t be done easily in a way that is acceptable to the health of the product. Junior engineers tend not to have to consider this constraint. Especially on teams that are more feature-mills, junior engineers will frequently add features in ways that are at best value-neutral, and at worst value-negative over the lifetime of the product.

This is intentional! All things exist in contrast, good and bad are paired, you must be allowed to fail in ways both varied and numerous in order to figure out what success even looks like. The technical growth that comes from this sort of work is the point.

It therefore worries me when I see newer engineers talking about their careers as though feature delivery is the final goal of technical growth.

This is a systemic failure to lead, but the pushing of this attitude is also arguably an intentional and malicious attempt to commoditize the craft of engineering to the benefit of a privileged few at the detriment of all software users. LLMs are a recent extreme accelerant to this trend, but they are not the cause, it’s been happening for a while.

For any given business need, I normally consider dozens of approaches to achieve the desired outcomes. Some match the expectations of the ticket author, some don’t, but nonetheless fulfill the actual requirements. Some approaches are high risk, some low. Some manifest their value in that they require no collaboration with other teams, some only work if there is an expert available for integration. All are immediately viable, all have trade-offs, many are secret dead-ends that will make your product less competitive in ways that are utterly illegible to the rest of the organization.

Beyond even that though, there are sometimes viable options that leave the systems we steward in a better place than they were before, and this is important. You want to get exponential? Here’s where it happens. What I mean when I say better here is undefinable, it’s a highly connotatively connected property that encapsulates business necessities, predicting the future, interpersonal relations, technical realities, ethics & culture, etc. These options don’t always exist, but they will tend to stop presenting themselves if an organization habitually avoids/is unable to identify them, and will present themselves more readily in the inverse case.

Exploring the shape of this make better quality across different contexts is the actual game of software engineering, and doing so will take you much, much longer than merely figuring out how to deliver features faster.

Perhaps this is also still just the tutorial. I’ll let you know if I beat it.

* I’d rather stop using the word feature, it belies a false perspective on what good technical work actually is and how it comes to be, but given these blogs posts are supposed to train me how to write without over-qualifying everything I say, I’ll just make do with this footnote.

Here we go. First “real” blog, 30 minutes, white page. How do I even do this? Should I write sections headings and fill them in recursively? That’s how I do PRD’s and such, although it feels a bit too planned for something like this, I think I’m just going to let my fingers run.

As I said before, the primary blocker I’ve been having in my writing, and my projects in general, is trying to say everything I have to say all at once. I need to pick a small, tiny, minuscule topic, and somehow try to ignore how everything is connected to everything else.

Ach, screw that, let’s talk about one of the big problems. Agreeing on a definition of value.

How on earth are we meant to say one thing is better than another? I’m advanced enough in my career that I don’t bring this up so much at work anymore, as it’s not really a helpful conversation to have when trying to decide on a technical strategy. However, if folks aren’t reasonably aligned on this, your organizations effectiveness is going to be hard capped in a particularly illegible way.

I suspect you’ve probably heard of the concept of “Gel” when it comes to technical teams, I read about this first in 1987’s Peopleware: Productive Projects and Teams, I think that book coined the term. Gel is, to use a personal definition, the tendency for two independent agents in a system to come to similar conclusions without having to explicitly communicate. It’s telepathy by the backdoor, and it can exist when folks values align such that their intuitions and deductions tend to lead them to the same place.

Whilst there are some downsides to gel (monoculture reduces rigor), the upsides are great enough that organizations generally try to encourage it. Some organizations even manage to realize that this isn’t possible without some sort of shared consensus principles to derive value judgments from, which is where the fun begins.

To solve this problem, organizations tend to produce and publish lists of corporate values. In the most common case, these are assembled by consensus, are vapid, self-similar, self-congratulatory documents, and are completely ignored by the majority of people. Nonetheless, I don’t discount these entirely, the are a potential definition of value, and they get credit just for acknowledging that this is something that needs to be considered. You have to watch out though, as is the norm with initiatives concerning formal definition of dynamic concepts such as this, any org that manages to be successful probably didn’t need the artifact in the first place, and conversely any org that really does need something, will almost certainly be incapable of producing anything useful.

More commonly, where shared values actually come from is by humans doing what humans do naturally, manifesting values and culture in an undefined, unguided sort of way. This is best, but is also unpredictable. If you’re smart, you can try to build an environment that encourages this sort of thing, but you can never really guarantee it.

I’m not optimistic on the future of shared values. Work from home, despite all its many upsides, has clearly eroded the natural value-alignment that tends to occur when two people share the same physical space. At least in my experience in the UK, the best of this tended to happen at the pub, in that sort of tribal ritual/group therapy session I’m sure most of us who worked in tech pre-pandemic are familiar with. This was especially advantageous as discussions often didn’t have to be couched and distorted such to avoid damaging fragile executive egos. Keep in mind that any substitute mechanism of alignment that occurs during work hours will be subject to this constraint, so will again be hard capped on its effectiveness.

Some folks might be reading this and be thinking that sort of control over value alignment sounds appealing, we can make sure everyone’s on the same page from base principles right? I’m going to assert that it’s incredibly difficult to actually change a persons values and you shouldn’t even try. In fact I believe it’s impossible by definition, perhaps I’ll explain why in a later post.

Many may think alignment is about changing hearts and minds, but it isn’t, it’s more akin to intimacy. There is a gestalt understanding of what everyone in your org thinks and feels, it’s ludicrously multi-dimensional, impossible to pin down, inherently inaccurate, but it is there. If you can tap into it, you can massively reduce your communication overhead, and be able to work through concepts that would be actually impossible to deliberate on otherwise. Yes, there are going to be elements of it that make you uncomfortable, that you might find icky, counter-productive or even offensive. Nonetheless, acceptance is a prerequisite to intimacy, which is a prerequisite to alignment, which is a prerequisite to high performing organizations.

If you’re looking for a prescription here at the end, I don’t really have one beyond the solution that solves every organizational problem. Hire only the right people, surrender control almost entirely, and hope.

I suspect this is rather a familiar story. You're a regular person in tech, you consume a lot of tech media, and you've had a long and storied enough career that you've got things to say.

However, outside of a dry technical writing context, you've never written before. You try nonetheless, and discover that it’s rather difficult to get the words out.

Christmas has just come and gone, and I have dozens of half-finished essays sitting on my hard-drive. They are all similar in that they try to address enormous, philosophically dense topics, and they all fizzle out as I find I don't have good enough writing muscles to communicate what I mean in a way that satisfies me

This does not come as a surprise to me. I'm a bit of a psychedelically inclined person, and something that becomes evident in that space is that it's a simple enough thing to experience “the grand truth.” What isn't easy is bringing those revelations out of that dynamic space into a form that won't dissolve when exposed to the winds of consensus reality. Revelation isn't work, what is work is pulling those concepts upwards, negotiating with them, and mocking their conceptual dependencies well enough that they can be communicated in a way that doesn’t require absolute connotative alignment between individuals.

Boy, that sounds like absolute nonsense, am I going to explain what I mean by the above? No I’m not, that's the point. I am not yet capable of doing so, I haven’t developed the muscles for it.

Therefore, I'm going to write a blog a day for the next two weeks. Call it exposure therapy. They won't be significant or groundbreaking or particularly well written, but they are going to exist.