Elliot Morris

Quick one today. If you’re reading this, firstly, who the fuck even are you? Secondly, you might want to skip this one it’s just a bit of personal reflection, and not particularly insightful at that.

This will be my fourteenth blog post, which completes my humble goal of publishing literally anything each day for two weeks. Hooray, I have accomplished a thing I set out to do.

Will I keep it up at this pace? Definitely not. Whilst I have gotten quicker at producing these posts even over the short period I have been doing them, I have accomplished that by not caring very much about what’s in them. They are stream-of-consciousness, single edit-pass sort of things that never do a great job of fully capturing what I mean.

This was very much the intent, I was doing exposure therapy. It’s not possible to ever fully capture what you mean, even if you write books and books full of qualifications and clarifications. I need to remember that going forwards.

Here’s some specific musings that I at least find interesting on this process.

I’m still fearful of repercussions

I publish under my own name. Most of my online accounts are under my own name. Honestly, I find anonymity a little bit gross if you’re trying to be part of a community.

However, I’m also a full time employed professional, but not being in Silicon Valley crazy town, I get paid a normal amount relative to what I do. All I’m trying to say here is that I need to maintain my job, and I am fearful, given the writing style I have adopted to allow me to produce posts at this cadence, that I might rub some people either at current or future employers the wrong way. There’s a fair amount of working class anger in what I write, it’s part of me. Heck it’s part of most of us, despite the economic systems we exist in forcing us all to mask it from our betters the majority of the time.

See, right there, “our betters.” Bet that’d make you uncomfortable if you were some south of England trust-fund executive making a hiring decision. That in particular causes me some hesitation in how I present myself in the future. I’ve been expressing what I mean here crudely and in a simplistic manner up until now, and I worry that that’s dangerous for me. I suspect I will have to be more complex in these areas going forward, which will make everything a little more burdensome.

I’m not pleased with this fear I find inside myself, I fight it actively, and resent people who do not have to. I do not want to be afraid of speech, and I do not want to constantly have to mask who I am, even if there are repercussions. I think everything I do is done better when I am being bold.

Speaking about LLMs is addictive

I wrote more posts than I expected to about LLMs. I have more posts still to write about LLMs. The whole space is driven by dopamine addiction and I am no exception.

You’ll note I say “LLMs” instead of “AI” when I can. I think that’s important. Let’s be precise about what we mean.

Writing how I speak

I have made no effort to develop a “writing style”, if such a thing exists. I’ve been writing how I speak. I wonder if this is a good idea? Given more time to craft these things, perhaps I will delve a bit more into the academics of writing. God knows I believe the form a piece of technical implementation takes effects its second and third order effects greatly, I don’t see why that would be any different with writing.

Spellcheck your work you moron

One of the few people who actually reads these things mentioned how poor I am at grammar and basic spelling. It’s true, I’ve never bothered to really try on this because it doesn’t bug me. I know what I’m trying to say. However, I also know that it bugs others, and can even lead to legitimate misinterpretation. Just run a checker Elliot, it’s not that hard.

got fast pretty fastly

The first few of these posts took me three or so hours all told. This one will take me about thirty minutes.

I’m not bragging. The quality of these things isn’t great. Luckily, I suspect no one but a few of my close friends is reading them at the moment.

Going forward, I don’t think I will stop writing, but the next test is to try and amp the quality of these things up just a tad, without losing the ability to finish a piece of writing. Let’s see how that goes eh?

Dad. Why does the sun go down at night?

Ah! Good question my sparking and intelligent boy. You see. The sun is a giant flaming ball of gas in space, and the earth is actually rotating, so what looks to us like the sun going “down”, is actually us rotating so we can’t see it anymore!

But why?

Well. Because you see, my mellifluous and unique offspring. Objects in motion, such as the earth, do not stop without a reason. In space, there is no air to slow you down, so it just keeps spinning.

But why does it spin?

My increasingly aggravating child, the earth was formed a long time ago … and, um, things were always in motion since the big bang, so it has just … always been spinning?

Why?

...Ask your mother.

---

This delightful little exchange is an example of infinite regress. If you assume that all effects have causes, you can do very fancy things, like try to assert the existence of a non-contingent creator god. It’s a fun hobby for a lazy Sunday.

It’s also arrogant. Adults realize that they can’t hold the entire causal chain all the way from observed phenomenon back to the creation of the universe (and beyond!) in their heads. Children, tiny fools that they are, have not learned this yet.

Paradoxically, the ability to be able to perform this sort of thinking is the main thing that matters in differentiating good technical thinkers from bad, and that is why I exclusively choose to hire children. End of blog.

Wait, no, that’s not right. Children have all sorts of other problems, and I have been informed there are legal issues. Back to dealing with adults, adults who, through engaging in a culture that would much rather the working class did not question things, have been indoctrinated into thinking that they simply cannot understand the complexities of the world. Financial systems, political systems, computer systems, they’re just beyond you, let the smart rich people deal with them.

Wrong. Obviously wrong. Few things are actually that complex when you get through all the obfuscation and accidental complexity. You can understand the world around you fully. You will be considered arrogant for believing this.

But Elliot, I hear you ask, you are being arrogant! Didn’t you just prove that you can’t actually do this? You’d have to go back to the beginning of the universe every time?

Correct! Congratulations on passing the first test and not blindly believing whatever I say. Luckily for us, we get to apply constraints to our reasoning. What follows are the two constraints I think apply to most software organizations, and allow us to formally break the infinite regress problem when doing technical planning.

• Computer hardware can be assumed to exist, and behave according to its published specifications.
• The final goal of the endeavour is to generate revenue for the company.

Annoyingly these do come with caveats, although if they were bulletproof they wouldn’t be assumptions now would they. The first is obviously sometimes false. You need to be aware of that whilst simultaneously doing the reasoning that requires it to be an absolute truth.

The second is an oversimplification, and if you know me you know I don’t believe revenue is the actual goal anyway. Nonetheless, it does seem to be a necessary (albeit increasingly inefficient) assumption in order to sustain the bodies of the people that create real value.

Really any goal will do for the purposes of breaking infinite regress, this is a fiction that your senior leadership gets to simply create. The closer this goal is to the overarching goal of the entire organization, the grander in scope your project will be able to be, and the more impact you will be able to have. Even so, if you find yourself on a project where the stated goal seems unconnectable to the final goal of the company, you should probably still poke your head up and start asking questions.

With these two conditions, we have both a start and end to our previously infinite regress. We can start with our goal and trace the causal chain all the way down through our theoretical systems terminating with the behaviors of the computer hardware that we know exists because we have assumed it.

Most companies will also add the following to make things easier

• Third-party computer software can be assumed to exist and behave according to its published specifications.

This is becoming even less true as LLM rot infects our entire industry, but it’s still true enough to be carrying on with. You may have to perform more software audits than before to sustain this assumption.

Organizations will have loads more of these, normally not just undocumented, but unconceptualized. They exist in a miasma of common wisdom and good practice and constantly change over time in the most frustrating manner. Keeping at least a loose handle on that change is also a necessary skill.

It startles me how difficult I find this to communicate. The behavior I tend to observe isn’t so much that people are bad at this, it’s more that they don’t realize they are allowed to do it. How many of us are doing our technical planning entirely through vibe or blind trust? I’ll grant that even with these assumptions known, you still have to rely on estimates and some educated gambles to close gaps of ambiguity in the causal chain, but that’s different from living in a world completely divorced from cause and effect my guy.

I’m getting a bit long winded for a daily blog, but before I go I will gesture briefly at one more concept, which I am going to term the strong and weak forms of causal technical thinking.

The weak form goes something like :

• We should do X because Y
• We should do Y because Z
• We should do Z because it has worked before.

This is pretty great. Yes it’s a shortcut that relies on heuristic, but observation of the past is a pretty reliable heuristic. Probably most of what you do should be this. You can also rely on other heuristics like industry best practice, but be warned. Best practice can be unreliable, presented as a near global truth when it is in fact appropriate only in very specific contexts. Apply care.

Even a well justified weak formulation, outside of being easier to achieve, is strictly worse than the strong form, which traces the causal chain in your specific context all the way from first cause to final effect. When I say this, I mean you can assemble, in detail, the specific function calls and data exchanges that happen throughout your entire stack in order to support the workflow that delivers the value you’re after. You will also be able to tell me why that specific workflow is the workflow that best delivers that value in human terms, and you will be able to connect those two lines of reasoning together. You will be able to do this without relying on any thought-terminating shortcuts outside of the global presuppositions covered earlier.

If you can do this, you’ll learn that you can estimate projects significantly more accurately and with fewer surprises, and have much greater confidence that the work you are doing is not going to go to waste.

This is practically impossible and takes forever. You have to talk to a lot of people, read a lot of manuals, know the trade-offs for common implementation strategies and architectures, and still have to run a bunch of experiments. I certainly wouldn’t say I’m very good at this, it takes a lifetime, although even being able to make the attempt seems to be becoming a bit of a rarity.

Importantly, the closer you can get to the strong form the better. There will be gaps, and you will have to bring in more assumptions (such as trusting what colleagues tell you) in order to complete the chain. Despite this, every extra link you place in the chain reduces the probability that your organization has missed something, that they are unaligned, miscommunicated, just plain wrong. It’s great stuff.

If this seems out of reach to you and you still want to be a technical leader, you better get practicing. I promise, despite what the entirety of modern culture is telling you, you can do this.

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.