Elliot Morris

Not even I, dear reader, am perfect. It’s hard to admit, but I have problems you know, deep shit.

I do plenty at work that holds me back. However, I still choose to do those things because they are good to do, either good for my colleagues, or good in the sense that they manifest value. This isn’t a list about that, this is the stuff that hurts my career, and is, in my opinion, not good.

#1 – Public anger

If I have a cardinal emotion, it is most certainly anger. All my reviews throughout the entirety of my career have been on this theme. Be more timid, give people more time to catch up, stop holding people to account, etc. I have tended to disagree with this feedback, I still do for the most part.

Anger can be a positive force, it is responsible for me being where I am today. It drives action, generates alignment, can shock people out of lethargy, etc. I tend to look on angry folk quite favorably, it means that they care, and that makes them more useful to me than most by default.

However, public anger, specifically when people look to you for leadership, is something I am learning can be less than helpful. Would you look to a leader who seems not to have it fully together, who seems to be panicking? This is the person who is stewarding The Plan, it doesn’t inspire, it mostly just gives folk the ick.

I have no intention to quell my private anger, directed towards friends and colleagues I trust can handle it, but I need to put a lid on it in public spaces.

#2 – Lack of executive function

Yep, I struggle to do things I don’t want to do. Boo-hoo, cry me a river. Look, I’m not looking for sympathy, I have figured out how to deal with this. I try very hard to make sure I’m working on inherently motivating stuff, because I am trying to deliver value and that is where it best comes from. However, that can’t always be the case, especially when you are trying to develop other people. You can’t hog all the self-actualizing work for yourself, it’s selfish.

My coping strategies tend to be deadline based, artificial or otherwise. When this manifests, it manifests as me working very little during office hours, and then doing the ol’ 10x engineer fugue state for 48 straight hours, interrupted briefly by a couple of power naps, over weekends.

This, to no ones surprise, does not scale, either practically or emotionally. The implementer side of my work is no longer the most impactful part of it. As much as I would like to lock all my colleagues in a room for three days and blast through 6 months of technical strategy alignment in a caffeine fueled productivity frenzy … well I tried and they gave me a very stern talking to, so I need to figure something else out.

#3 – Not keeping confidences

I want to be extremely specific here, because despite the clickbait section title, I do keep confidences, in the vast majority of cases.

I don’t know if everyone is like this, but when speaking, I do not pre-conceptualize the words that are leaving my mouth. The entity that is speaking, heck, the entity that is typing, is a different thing to the entity that causes the inner monologue when I am thinking.

For this reason, I have to catch myself. I realize, normally before my mouth moves, that the thing I am pre-vocalising should not be said, and I stop myself.

I do this for colleagues and folks more junior to me by instinct. They are protected. I am not concerned that I am accidentally breaking their confidences. I would have assumed I was doing it for those above me also, but I have realized that I am not.

Specifically, I am holding confidences for anything that I feel is important. I have not spilled the beans on any important or impactful secrets or implicit confidences. However, you see the problem, things that I feel are important. Not that they feel, that I feel.

This is a breach of trust, and I only recently realized I was doing it when I casually dropped a, in my opinion benign, tidbit a technical director had shared with me in a 1 to 1 as a way to lend authority to an argument I was making to a peer. The technical director had told me at the head of the conversation, explicitly, that they were talking to me in confidence, and I realized after the fact that I had breached it.

I can only assume I have done this on other occasions. My instinctual safeguards were not sensitive enough to trigger if the secret was from someone “above” me, whom I do not feel the need to protect, and I do not instinctively feel the thing is important. In my estimation however, this is an irrelevant heuristic. Confidences are a promise, my opinion on the importance of their contents do not matter.

I may link this article to the technical director in question. If you are reading this, I am sorry. Rest assured that I am reasonably certain you would have agreed with me that whatever it was (seriously, it was so minor I don’t even remember) wasn’t a big deal, but you know, I’m not proud.

---

Boy, being honest on the internet, and under my own name too. Will I ever get hired again? Will I even keep my current job? You’ll have to tune in next time to find out.

Let us start, as all good things do, with preconditions:

1. Your organization used to take and publish meeting notes by hand, for at least some meetings

2. At least some of these notes are now being written automatically via LLM transcription services.

This is clearly acceptable to many, or even most people. It’s easy to see why, nobody enjoys taking meeting notes. In times gone by we employed people full time to deal with admin like this, then everyone ended up doing if for themselves when personal computing became a thing, and now we live in the future and nobody has to do it.

So, these notes, you’ve read them right? You actually reference them, you use them? I don’t, because they’re useless. You may disagree with me on this. If you did, you’d probably say something like : “Yes Elliot, they are not as consistently good as human notes, but they’re damn close, and it’s well worth not needing a dedicated note-taker.”

We disagree. However, I’d like you to keep following me on this, because I think you might agree that this isn’t the actual reason that many of us have transitioned into relying on them.

I contend the actual reason is that we never actually cared about meeting notes and we still don’t. We may have intellectually understood they are valuable, but we didn’t care, we intuitively didn’t think the juice was worth the squeeze, and were oh so eager to give up writing them. All LLMs have done is given us a convenient way to abandon parts of our jobs we don’t care to do, yet still pretend that they’re getting done.

Take this example: Cops Forced to Explain Why AI Generated Police Report Claimed Officer Transformed Into Frog

"Despite the drawbacks, Keel told the outlet that the tool is saving him “six to eight hours weekly now.”

“Despite the drawbacks.” I wonder what they think the drawbacks are. What is the purpose of these police reports? If it's acceptable for them to have mistakes in them that nobody is responsible for, I wonder at how they be thought of as fit for purpose? If they’re not fit for purpose, but you’re still okay with the trade-off, wouldn’t it be better to just stop taking them? I bet this evokes a reaction in some of you. Not take police reports? But then how can we verify what happened?! How indeed.

I can feel the anger bubbling as I write this, because I bet there are commandments in larger orgs and governmental departments like this one that there must be written notes. Maybe these commandments exist for a reason. LLM notes obviously should not satisfy these unless nobody cared in the first place. Such concrete rules must exist because there is a need for a reliable, audit-able paper trail. If you are plugging LLM notes into a system designed to enforce this sort of paper trail, you haven’t achieved your goal, you’ve just turned what used to be a valuable activity into a compliance ritual. If what you do actually matters at all, this causes real harm.

But heck, it’s hard to blame folk on this. Whilst I am sure some people are abdicating their actual responsibilities by deferring to LLMs, I bet the majority of people are being forced to do this sort of thing pointlessly by terribly managed organizational systems, and I bet they don’t have the power to do anything about it. It is important we do not confuse the two cases. We must not allow necessary responsibility to be abdicated under the auspice of escaping useless procedure. We should instead remove the useless procedure, not hail the workaround as a revelatory new solution to a real problem.

Putting that aside, the more interesting behaviour is how the people empowered to make these calls tend to get stuck on problems where the thing being sacrificed, in this case meeting notes, clearly have some value. If something has obvious value, folk are afraid of being seen as responsible for losing that value, even if the trade off seems worth it. They need a scapegoat, a way to avoid that responsibility, in the same way lumbering organizations “need” to employ management consultants at great expense to tell them to do things they had already decided to do.

You simply must be comfortable making these sorts of value trade-offs, the ones that demands a sacrifice on one side of the scale, if you are to be an effective leader.

You’ll have cottoned on by now to how this isn’t really about LLM meeting notes. Understand what you are doing. Keep doing the things that are about personal responsibility or provide value that is worth the squeeze, and just stop doing the things that are not worth doing. Crucially, stop replacing what you were previously doing with shambling husks of worse than useless ritual and workarounds in silly attempts to pretend you’re making a pure improvement and not a trade-off. All things are trade-offs, and trade-offs don’t need to be perfect, if they were, they wouldn’t be trade-offs.

Yes, this involves honesty and personal risk, responsibility is the name of the game. Are you this timid when you work on the more substantial parts of your organization?

*Elliot turns around, and locks eyes with the entire white collar economy staring sheepishly back at him*

Oh. Right.

There's this foundational assumption when you work inside market systems. Good things will perform better than bad things.

It's the essence of competition right, it's difficult to define good, but there's something there? Some sort of quality that creates a differentiating selecting force, causing, eventually, only the cream to float to the top.

I no longer believe this is the case.

Does it seem to you that revenue matters anymore? Is anyone acting as if they care about profit, let alone providing a good and useful service to another human?

What seems to have happened is that, in the most amazing upwards shift of wealth ever seen, we have reached a tipping point. It used to be that the path to success, especially in software where manufacturing costs are zero, was to convince a lot of people to use your product. This, thought of in the broadest possible terms, was a good thing in the utilitarian tradition. It was a market that optimized for the greatest possible value being delivered to the greatest possible number of people. Huzah!

No. Not Huzah. Even putting aside all the obvious distribution problems of market economies, it doesn't work like that anymore. We are now back to what, thinking historically, was the norm for the vast majority of human history. Wealth exists primarily in the hands of the ultra-elite, and they don't really have much incentive to use it in ways us regular folk would consider rational.

I presume these people are humans, and thus want human things. For the ultra-rich, the only human thing they don't already have is self-actualization. They are trying to buy it.

Therefore, there is no longer any need to make a product that is valuable to lots of people, all you need to do is appeal to one specific person. You want to make them feel special and excited and invigorated and important, then maybe then they'll throw some money at you. You made them feel good, and now they want to own you.

Investor cash is ruining societies, it's fucking with the fundamental forces that drive the creation of value for the vast majority of people. Why is AI being shoved into every software product you interact with? It’s because some ultra-rich person thinks it will change the world, and thus make them feel important for having been the one who changed the world.

It's also fucking with my life personally because I have no idea how to operate as an engineer in a system where there is no foundational source of value outside of one specific persons predilections.

Don't misunderstand me. Obviously Jeff Bezos isn't personally choosing which acquisitions to make, the people under him are. The Lieutenants, the Royal Viziers. These are the people you need to manage. It's their job to make him happy, and it's your job to convince them that you can do that, even if it means completely abandoning your mission and focusing exclusively on the one thing some high level executive at Meta found “cute” during your product demo. There is simply too much irrational cash on the table not to do this.

I could make predictions, about how mass-market software will continue to be enshittified. About how the ultra-wealthy and their sycophants will be served by boutique software and hardware customized for their specific use. That software won't crash all the time, it won't force AI into their faces, it won't try to upsell them with dark patterns, but don't worry, it'll basically be the same thing the common man gets. 🙄

I expect the craft of software engineering will eventually have to contend with this. Maybe Agile will finally become appropriate in the majority case, given that we'll be working exclusively for capricious children with no idea what they actually want.

After I post this, I'm going to go back to trying to manifest real value in the common good, because I do not know how to operate in any other way. Be under no delusions however, we are entering a new age of Kings.

I am still hopeful there may be ways to reverse this. If there’s one thing I believe, it’s that there are more people willing to consider radical remediations to this shift than is commonly believed, if someone could just give them a push.

I don’t lie at work. However, I don’t lie less than I used to.

Weird eh? If you’re my manager, stop panicking. I’m certain I do not lie by your definition, but it took me a while to figure out the difference between what I believe is the common definition of truth in an organization, and the definition I was operating under. Learning this helped my career, and has saved me a fair amount of psychic stress when dealing with collaborators and stakeholders.

I used to think telling the truth meant something like this :

Respond to queries honestly without obfuscation, and make sure my interlocutor understands all relevant context.

If you have decent social skills, you've already seen the problem. All relevant context? Elliot, you're a crazy hippie who thinks reality is literally made of connotation, did you ever shut up?

No, no I did not.

As I moved into positions where communication become the more important thing, I did manage to decode the unhelpfully obfuscated feedback I was getting from frustrated colleagues. I worked through my own moral panic around “hiding” context from people who might need to know it, and eventually landed on a more useful definition.

Answer direct questions honestly without obfuscation, and make sure my interlocutor understands important relevant context.

Only a one word diff, but this radically changes the game. Suddenly I need to make judgment calls, trade-offs. What is important for this person to understand, what would just add noise? Are there things which might technically be helpful, but the communication cost outweighs the potential benefits of establishing the context? This is obviously harder to do, and a skill you must develop.

Notice how this involves taking on some amount of responsibility. It’s on me to decide what context is important and what isn’t. This takes decision burden from the interlocutor and places it onto my shoulders. It’s uncomfortable, but it’s part of why they pay us.

I still believe that you need to be proactive in communicating context. Simply answering questions put to you without attempting to explore the dynamic space of why the person is talking to you and what they need out of the conversation is lazy, and abdicates responsibility in the other direction.

A frustrating part of this is that, for some reason, the need to develop this skill tends to go unspoken and unacknowledged. I suppose people are uncomfortable giving people feedback on conversational abilities, as it’s not a “technical” domain. Perhaps other folks just understand this more intuitively that I do.

Whatever the case, figuring this out helped me a bunch, maybe it will help you as well.

Ah tickets, they go by many names. Work items, stories, tasks, spikes, features, backlog item, etcetera. We love them so.

They’re all more or less the same thing, a little digital post it note where you can write down the what and why of something that needs doing. They’re also often harmful to the successful delivery of valuable software.

Why is this? It’s the same old story. Doing anything, absolutely anything, has cost. Clumsy ticketing systems, even in relatively small orgs, manifest this cost in some particularly gnarly ways. I’m gonna talk about it.

I contend that when you go to log a ticket in whatever change management system you use, you are expressing one of two things:

• There is a problem that I cannot resolve myself, I wish for someone else to address it.
• There is a problem that I cannot resolve myself right now, I wish to delay addressing it.

Neither of these things are unreasonable, although I do think they are unfortunate. Would it not be better to be able to address your own problems, and it wouldn’t it be better to be able to deal with any issues you see immediately, rather than needing to delay? Nonetheless, you can see what this sort of ticketing buys you organizationally, specialization and the avoidance of context switching, both of which can be helpful.

Even so, there are additional trade-offs that come just from the act of logging tickets. This point of this article is to contend that these trade-offs, more often than people acknowledge, outweigh the benefits of logging tickets at all, and in many instances it would be better to record nothing.

Before I break down the details, I need to address a philosophical point. I suspect some will balk at this idea. Record nothing at all?! That’s absurd! In my experience, this attitude comes from an instinct that it is inherently virtuous to have a single store of all context around a project. It is simply good to write things down. I contend that this is an example of religious thinking. Why is it good to write things down, what specific benefits does it have to the successful delivery of a project? What specific downsides does it have? We are engineers, we do not get to abdicate our duty and rely on heuristics unconnected to final value.

That isn’t to say that there is no organization where writing down most things is the correct trade-off to make, but in my experience most of the foundational thinking in this area is unconsciously sourced from various scrum industrial complex assumptions, and never examined in an organizations specific context. There is no one correct way to develop software, we must have realized that by now.

That being said, here are the things I most often notice as issues with logging tickets.

Expressing the wrong thing

Are you the right person to write this ticket? Do you know what the fuck you’re talking about, and can you express it well enough that it won’t cause an overburden of confusion?

People tend not to get trained how to write tickets, and software is complicated and often non-deterministic. People do misinterpret, and they do make assumptions on what the “fix” to their problem should be. This creates overhead on the part of the person who eventually needs to deal with this ticket. They have to do work to decode and understand what is actually going on, which isn’t free as they’ll have to agitate the organization in order to do this. In poorer technical cultures, they will simply do what the ticket tells them, delivering net negative value as they build the wrong thing. In these cases, it would be better if the ticket had never existed at all.

Temporal Rot

Tickets are static artifacts, they don’t update as time passes and underlying technical and social context changes. This is obviously a downside of the medium, and it’s a big one.

Some organizations habitually delete tickets that are older than 12 months or so. I think this is almost always a good idea. Temporal rot causes all the same negative outcomes of the ticket being malformed in the first place, but it can happen to any ticket, no matter how well considered it initially was.

I have seen PMs place tickets over 3 years old into backlogs without understanding what is written in them beyond thinking that the title relates to what the team is trying to do. It sounds trivial, but this can cause such utter chaos, especially on teams where the engineers are not as confident or outspoken as they should be. Please stop.

Illusion of Understanding

Fans of Seeing like a State may retort that yes, these are problems, but we do them for legibility. They may cause the organization to be inefficient, or even clumsy, but it allows the organization to make effective decisions which is, in the long run, much more important.

My friends, has that ever been your lived experience?

Whilst I don’t deny this sort of legibility is possible, you don’t get that for free. An under-considered (ie, most of them) implementation of ticketing will lead you to having less legibility, not more, as members of your organization merrily delude themselves into thinking they know what the fuck is going on.

I don’t think I need to harp on this one too hard. I’m sure you’ve had non-technical PM’s, leads, or even engineers, who seem to be doing nothing but playing ticket tetris. You’ve had people who seem exclusively concerned with progressing the ticket and not at all concerned with the value it would represent if manifested. Unfortunately, we as an industry have been hoodwinked into believing that this sort of work is legitimate and valuable enough to justify entire positions.

This is especially frustrating as I am certain the people doing this sort of “work” feel frustrated and impotent too. There is a need for a “true PM” role, I’ve worked with a rare few who were overwhelmingly valuable. They did this by caring about tickets only as much as it helped them, they were much more concerned, and much more fluent in, the tangibilities of the product itself. Let us free these people from jira-jail and allow them to be valuable once more.

---

Experiencing all this, one might start to think that delivering value, or even making profit, isn’t really the point here. One might start to think that control, or even the illusion of control, is the output we’re trying to produce from these machines. Now of course I would never say that the current economy is exclusively setup to trick those at the top of our socio-economic hierarchy into believing they have self-actualized, like the no-clothed kings of old. Me? Never.

Putting that useless (but fun!) rant aside, we must all realize that you cannot contribute to successful software delivery if all you have to ground your interpretation of any given ticket is the information contained in the ticket alone. The map is not the terrain, and ticketing systems, treated naively, are maps with more noise than signal. If you find yourself logging a ticket, ask yourself if this ticket is likely to be materially useful. If not, just don’t log it, your colleagues won’t thank you, but I will.

Hey Elliot, you’re still an AI hater right? What would it take to convince you?

Firstly, please call me Mr. Morris. Secondly, you say “still” as though my hatred for AI is related to it’s effectiveness and not to how its existence shatters the democratic principle of laws applying equally to all the human participants of a nation state.

Okay fine, if you really wanted to convince me that heavily LLM driven software development practices (because that’s what you must mean to justify … *gestures broadly*) are now an effective way of producing valuable software, you’re going to need to build and sell a software product to a specific set of conditions.

I’m going to preface this by saying this is what would convince me, it is not a fair test, and I’m a picky bastard. I’m talking about being convinced to change my mind, which means I need to really be certain that specific suspicions of mine are not at play. I’ll explain what I mean as we go.

I’m also going to try and make these relatively falsifiable. No “Produce real value” or any other metaphysically adjacent requirements. Still, I’m sure anyone attempting to actually test me on these will find it frustratingly impossible to agree if any given example “counts”. Too bad.

---

#1 – Displace the market leader

If LLM development practices are the future, and are an improvement, it stands to reason that eventually a company driven by them will disrupt and replace.

This only makes sense if we are in at least a semi-rational market environment, and development practices actually, you know, matter when it comes to organizational success. If either of them are untrue then nothing we do means anything anyway, and this whole LLM kerfuffle is a massive waste of time and money.

#2 – Do so with a product unrelated to AI

I’m not sure I’ve ever seen a properly off the deep end AI booster ever not be developing an AI product. It’s normally some sort of LLM orchestration frame, or context management system.

It goes without saying this is deeply suspicious, you can’t manifest value solely by eating your own tail.

#3 – Do so in a “traditional” market domain

Let’s take that thinking a step further. To be truly convinced, I’m going to need to be sure you’re not operating within an irrational market environment.

This means “new” domains are out, I can’t take the risk, they could be pump and dump bubbles. Any hype driven domains like crypto, metaverse or anything to do with speculative investment are also way out.

Here are some examples of domains that would satisfy me : consumer or server operating systems, GIS software, FEA/MBD simulators, accountancy/tax software, office suite software, CAD software. You know … stuff that’s actually important.

#4 – Your “engineers” never edit source code

This one may seem wild, and I agree, it’s not fair. However, I’m more aware than anyone how often a small number of motivated engineers can keep a ship moving forward by stealth, despite destructive and baffling behaviors by leadership.

I need to ensure that this is not happening to be convinced. Therefore, no engineers editing the code, ever. I’d quite like to weaken this requirement as even I grant that there’s a huge gap between full-vibe and LLM assisted practices, but I can’t think of a better way to control against engineers compulsively trying to produce working products.

#5 – Make a real profit for three straight years.

Finally, actually make some goddamn money. Three years seems like a good amount of time to prove that you’ve got something sustainable and aren’t riding a bubble. The length of time should also guard against the greenfield problem, as I’ll need to be shown that you can maintain a product to the satisfaction of your customers, whether via traditional maintenance or newfangled AI driven total rewrites.

This has to be real profit too. No weird accounting tricks, no counting investment as profit. Customers need to freely choose to give you their money, ideally they will also be happy about doing so. This also means that you need to be doing this in a non-subsidized token environment, unless those subsidies can be expected to remain available in the long term. I’m confident enough that three years is long enough for that to resolve, although the market is extremely good at staying irrational so perhaps this is too optimistic.

---

These would convince me. They are not proofs. I can imagine LLM driven development being useful without any given product having fulfilled these conditions, especially the traditional market domain one, which has regulatory capture issues to contend with. I also don’t think an LLM driven company that fulfills these conditions has proven anything, not formally, these are mostly market based and market success doesn’t necessarily equate to value.

Nonetheless, I am a human living in a market economy so they hold a large psychological sway, and these conditions being met would cause me to have to re-evaluate my “LLM systems cannot produce useful value by definition” ideology.

You shouldn’t really care about convincing me though, I don’t matter. If you’re really confident you’ll achieve all these things and keep it to yourself, why bother making a fuss, you’ll have already won.

Hold onto your hats, brave and controversial opinion alert!

It is neither inevitable, nor desirable, to ship software containing bugs.

Are you shocked? I'll admit I'm a little surprised at how viscerally certain kinds of people in software react to this. I suppose it goes against the ever-infallible common-wisdom. Let's unpack it.

Obviously it's impossible to guarantee that something works, right? We have no reason to believe software is some special animal here. Cars, Planes, Agricultural machinery, none of these can be relied on to work correctly, even brand new.

Taking my tongue out of my cheek, this is sort of true. Cars break down, but there's a difference. We expect our cars to start. It's strange when they don't. Furthermore we can tell if a car is likely to start reliably and when it is not, there are experts capable of doing that.

Given this, we should move forward under a weakened and more realistic assertion of what working software means. I would define it as

⦁ Reliability in the 99%+ range.

⦁ Ability to inspect software and make an informed decision on whether the above reliability guarantee will hold in any given environment.

Okay great, with a definition that matches physical systems, we're all good. This is how serious software works currently right?

Does it fuck.

The next argument goes that, well, you can get software that operates like this, if you're willing to put an undue amount of effort into paranoid coding standards and triple checking everything, but it's just not worth it. Software isn't that important, the risks involved with delivering broken behaviour is so low, moving fast yields better outcomes in the long haul.

I have so many objections to that line of reasoning, here are some of them:

Plenty of software is vital. You may roll your eyes at this. Of course if you're building a space shuttle you're going to do things differently. That's not really the point though. Do you know how your software is used, really? Most important software is components and libraries, or otherwise used as an element in a grander workflow. Do you think your software gets audited? Do you think we, as a field, are capable of auditing software?

Where is your disclaimer that states you have no real idea if your software can be relied upon in any given environment? Don't balk at this too soon, it's not as ridiculous as it sounds. “This software is exercised in X environments to Y degrees of rigour. It may work in other environments but we make no guarentee’s.” is good enough. Understand what your software is and be honest about it, no one's going to judge you.

Why does software get a free pass in terms of the responsibility we take on? If my new boiler started exhibiting strange, inscrutable behaviours three months after install, am I just to shrug? No, someone is responsible for that. I'm not here saying that I need to get angry at the installer, humans do make mistakes, but nonetheless it should not happen and someone needs to remedy the situation, and make sure it does not happen again.

Software seems unique in that producing it seems to come with little to no personal or organizational responsibility. Our craft cannot be the bedrock of the global economy and simultaneously not important enough to give a shit about.

I think we need to be held legally responsible here, as software engineers, maybe even as individuals. Doctors don't get to hide behind “The hospital made me do it,” so neither should we. I know that's scary. I know it's hard to imagine working in ways where we are accountable, but we can get there. Not only will this make software better, but it will also imbue engineers with more agency. When a profession is legally liable, that profession will be forced to develop mechanisms to push back against enshittification pressure, there will be no other option.

Reliability doesn't have a 1:1 correlation with cost. Think of the most reliable appliances in your home. Whilst they may not be the cheapest , regretfully there is still a market for corner cutting even in physical goods , I bet they are among the cheapest, especially in relation to expensive high-complexity gadgets and gizmos. This is because the manufacturers of those things figured it out. They removed the ambiguity from their craft and turned it into a science, which then allowed them to cut costs in controlled, comprehensible ways.

Software as a field needs to advance. No it's not something you can just do as an individual contributor or even as a company, but it's possible if we all pull together. We need standards bodies, we need professional accreditation. We probably need to reduce the amount of working software engineers in general as we hold ourselves to higher standards. It'll be a long road, but don't let a perverse system motivated by ever increasing wealth extraction convince you that what we're doing currently is either good or inevitable. It isn't.

Everyone’s having a-ha moments with LLM’s. The new GPT 5.2 and Opus 4.5 models have once again changed the game, they’re now good enough to write 90% of all your code, even skeptics are turning around and hopping onboard. Wow! Can’t wait to see it.

Whilst I’m not being totally sarcastic in my desire to have my mind changed, you can tell from my tone I’m not there yet. What folk speak about concerning their a-ha moments does not resonate with me, to the extent that I wonder sometimes if we’re even in the same profession. Join me in popping the cork as I officially become an LLM malcontent.

Greenfield work

Obviously LLMs seem good at this, because engineers who can barely invoke a compiler also seem good at this. Greenfield work is so delightful because you can’t really get it wrong, there are no awkward pylons jutting out of the ground or ancient utilities you need to know how interact with just so. Just how many of you are doing greenfield work as your main thing? Am I out of touch?

I remain suspicious of greenfield work that happens quickly. LLM’s or no, if you show me a lot of visible progress all at once for a new project, I am going to assume you’re building a toy that is ignoring all the sticky complexities of the problem domain. This was true before LLM’s, and is especially true now.

Publishing open source repositories

Seriously who the fuck cares. Your project is probably pointless. Before LLMs there was an oversupply of unproven toy projects, and now that’s even worse. Publishing a project that doesn’t get adopted is negative value. That’s fine, I’m proud of you, everyone needs to learn. But you must realize that until you’re actually supporting serious users you have achieved less than zero when it comes to delivering value.

I suspect many people have fallen into the trap of thinking that the code that makes up their project is what gives it value. Code has no inherent value, it only has inherent cost.

Writing better code

“Claude writes better code than I do”

What the fuck do you mean?

Like what, it’s prettier? More performant? Has fewer edge cases? Runs on a larger swathe of target architectures? Better documents its preconditions? Has fewer dependencies? Will put you in a better world-line 6 months from now such that you can trivially integrate unforeseen use cases? Has sniffed out the way the wind is blowing among the technical directors and CTO and has left its options open for the big change that everyone says isn’t going to happen but you are pretty sure actually is?

This is one I just don’t understand. “Good code” obviously doesn’t exist outside of an extremely trivial set of metrics, and we’ve never even agreed on what those are!

However, Bad Code does exist. There is code with memory leaks, code that crashes, code that doesn’t report errors richly enough. Maybe this is what people mean, LLM’s tends not to output Bad Code? I can agree with that.

“Claude writes better code than I do”

Oh no.

Better search

Okay, I care about this a little. I think this is what most people are practically using LLMs for, both inside and outside the engineering profession. Whilst I am a claude code enjoyer, the majority of my LLM usage remains simple questions.

I’m going to try and leave my intense, seething rage at the absolute devastation of the commons LLM companies enacted in order to pull this off aside, in order to make a smaller point.

Traditional search is better than LLMs. Google used to be good, it’s one of my great fears that people will forget this. People called it magic in the same way people seem stunned by the capabilities of LLMs today. It was telepathic, it just knew what you wanted. You could even learn google-fu and make it even better. I would instantly remove all LLM tooling from my workflow if it meant I could go back to 2015 google, but alas, the need to extract wealth has eliminated that possibility, I doubt the internet as it stands could even support search that good anymore.

Do people not realize the same enshittification is going to happen with these tools? We are being forced to become dependent on these centrally controlled systems for something as essential as easy access to information. It’s disgustingly transparent, and obviously catastrophic in ways that reach beyond mere software engineering. Yet, here I am here typing questions into claude the same as everyone else, because it’s the only easy option. I hate myself.

Finally, a note on the discourse.

To those who think I’m being a moron, that I’m being biased, closed-minded, will be left-behind, etc. That’s great for you! The best part of your position is that you being correct makes me irrelevent. You have no incentive to argue back at me. Let my complaints hit the wind and become evidence of my idiocy. You’re going to out-compete me in the market anyway right?

Maybe show a little grace and let us losers have our tantrums before we are drummed out of the profession, you’ve nothing to lose either way.

I admit it! I maintain a shadow backlog. That is to say, I habitually spend time working on tasks that have not been prioritized by my team, but I have unilaterally decided are important enough to devote some fraction of my working week towards. I know, I should be ashamed. It’s a miracle I’ve not been chased out of the profession by now.

Luckily, I am in at a level of seniority where this is somewhat expected of me, even if that goes unstated for the most part. However, I have been doing this for the bulk of my career, and I’m here to tell you that you should too.

What I am not here to tell you is that you should prioritize your own gratification over the success of your team. Exploitative corporate structures aside, your team consists of your colleagues, and you owe it to them not to be a burden. (I know, this thinking can in its own way be another mechanism of control by the owning class, but not everything can be a class war my guy.)

I spend 10-20% of my time on my shadow backlog, and often drop it for months at a time when mainline work is more pressing. Sometimes companies formalize this as 10/20% time or Innovation Days. Whilst I appreciate the intent of these, I’m not a fan as it’s the flexibility that illegibility provides that makes shadow backlogs work for me, and frankly I don’t think employees need permission to be doing this.

That being said, take this all with a grain of salt. Shadow backlogs are not allowed. If you can’t do this without it adversely affecting the elements of your work that are actually important to your organization, you should not do it. However, if you find yourself just sitting there for extended periods of time, unable to muster any motivation, as I know a lot of us do, then keep reading.

Off the top of my head, here are some examples of things currently in my shadow backlog:

• Add mock injector functions such that particular service errors can be tested. There is some work coming up that will require this, and the mocking framework in our tests is haphazard and incomplete, I’d rather have the groundwork laid to avoid having to bundle the test complexity into the upcoming ticket, especially if more junior colleagues end up taking it.
• Finish up some gnarly work in our interop code generator around value types. The work this relates to got paused over the holidays, and having this done before we reboot will make the overall story simpler.
• Continue work on a side-bet of mine, involving an integration of our core framework into a DCC tool.
• Write a bunch of conceptual documentation for a client repository that I am the sole knowledge-holder for.

You know, before writing these out I expected that I would find I am disagreeing with many of the organizations prioritization decisions, but it’s not really that is it? It’s more that the cost/value calculation of just doing these, rather than communicating and planning and prioritizing, leans towards them being appropriate for shadow backlogging. I’m sure the specific texture of everyone’s shadow backlog will be different, but what I am sure will remain constant is that you, like me, will have more context than anyone else in these particular domains.

In particular, what I mean by that is :

• I have more context in technical minutia around areas of which I am familiar.
• I have more context over my own motivations and capabilities at any given moment.

The second one is the really important one.

Perhaps you’re a machine and can take any task given to you and churn through it. Fantastic, I’m proud of you, and you don’t need a shadow backlog for the same reasons I do. For the rest of us however, we are not machines, and are never going to be machines no matter what delivery framework we are placed inside.

A shadow backlog can serve as an escape hatch. There are times, rather frequent times for me, where I physically cannot motivate my hands and fingers to move such to progress a specific task. This sounds pathetic, perhaps I am broken. I don’t think so however, as I observe this behavior commonly in others, although people are ashamed to admit it. The arrogance of complaining that it’s hard to move your fingers to type code because it doesn’t currently speak to you? Bah! Don’t you know there are people in jobs who don’t have that luxury, who actually have to do labour? You pathetic, useless worm.

Maybe that’s true, but you know what, I don’t care. Shadow backlogs are a way of coping that works for me, and if you’re an employer who understands that humans are human, they work for you too. I don’t have to deal with the existential terror of finding myself physically unable to move forward on the one thing that is currently important, and the company gets a worker who is doing something rather than nothing.

The bonus win for everyone is that the things in shadow backlogs tend to be more valuable than the things that actually get prioritized for the reasons everyone knows but no one talks about.

As a closing thought, I’ll ask, are shadow backlogs an antipattern? I think probably yes. I have worked on teams where I didn’t need one. Communication was tight, values were aligned, the things we wanted to do and the things we needed to do were the same. However, we all know how rare and difficult this is, so I don’t begrudge this pattern as an effective coping mechanism.

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.