Building to Be Forgotten

On ego-less, stoic software development

There is a habit in our industry that we rarely say out loud, because it is dressed up as competence. We build systems that only we understand. We become the person who has to be in the room. We call it being senior, or being trusted, or knowing where the bodies are buried. What it actually is, most of the time, is self-protection. And like most self-protection, it makes the thing it is meant to protect weaker.

I have felt this pull myself. Working on a system that other people would inherit and depend on, there was a moment, small and a little shameful, where the temptation was to make it quietly mine: to leave fingerprints in places only I would know to look, to keep a few decisions in my head rather than in the repository, to be the one you had to ask. The pull was not malicious. It was just fear wearing the costume of value.

I want to argue for the opposite. For building software you are happy to walk away from. For making yourself, deliberately and as a matter of craft, dispensable.

The negative pattern

Most of the defensive moves in software are negative designs. They optimise for the engineer’s security at the expense of the system’s health.

Knowledge hoarding is the obvious one. If the only place a critical decision lives is in one person’s memory, the organisation is now hostage to that person’s calendar, mood, and tenure. We have a polite metric for this, the bus factor, and we treat a bus factor of one as a risk. We are less honest about the fact that some people engineer that risk on purpose.

Lock-in is the same instinct pointed outward. Tying a system to one vendor, one host, one framework, one output format, often has a quiet second motive: it makes the system harder to take away from the people who built it. A system nobody else can move is a system nobody else can take over.

Both feel like safety. Both are fragility sold as security. A system that depends on a person, or that cannot evolve without its original author, is not a strong system. It is a brittle one with good PR.

A stoic frame

The Stoics had a single idea that cuts through most of this: some things are in your control, and most things are not. Some things are up to you, your actions, your judgement, the quality and honesty of your work. Most things are not, whether you are recognised, whether you are kept, whether the thing you made is remembered with your name on it. Anxiety, they noticed, comes from gripping the second category as if it were the first.

Applied to software, this is unexpectedly practical. The part that is up to me is the craft: the clarity of the design, the tests that let a stranger change it safely, the documentation that puts the intent on the page instead of in my head, the generosity of sharing it. The part that is not up to me is whether I am still on the team next year. So I should build as if I will not be. Not from resignation, but from realism. You will leave the team. Everyone does, eventually. The honest thing is to build for it.

The engineer optimising for indispensability is trying to control the uncontrollable, their own continued necessity. The engineer who designs for their own departure has let that go, and is freer for it.

Skills are practised virtue

The obvious objection is that ego-less must mean value-less. It does not, and the reason is worth getting right, because it rests on a confusion about what a skill actually is.

There is a related confusion that runs through the industry, and it starts with the job title. “Programmer” as a role makes no more sense than “tooth-driller” as a description of a dentist. The dentist’s skill is not the drill; it is the diagnosis, the understanding of the patient, the judgement about what intervention will help. The drill is incidental. In software, the skill is analysing the business problem and, as a team, addressing parts of that problem using software. The craftsmanship lies in the architectural patterns of software engineering, not in the choice of framework or the current technology fad of the year. A framework is a drill. It will be replaced by a better drill. The understanding of the problem it was pointed at is the thing that lasts.

What you actually did was design an entire process and solve a problem. You controlled the workflow. You quality-controlled the output using test-driven development and evidence-based effect analysis. You measured the outcome. You are not your code.

Stoicism at its core is not a mood. It is an ethical code: a set of values you hold and then practise. Practice is the operative word. A value repeated, in routine and under pressure, day after day, hardens into a skill. Patience practised becomes judgement. Honesty practised becomes clarity. Care practised becomes craft. Your skills are your values worn smooth by repetition. That is what you actually have to offer, and it is not small.

So you share your skills, and you are compensated for them. There is no tension in that. The thing of value is the skill itself, the practised capability, and it is yours whether or not you hold on to what it produced. What you do not do is hold on. You do not hoard the skill, or the knowledge, or the code, as though giving it away made you less. It does not. A skill given away is still yours; you walk out of the room still able to do the thing. That is the strange economics of craft: it is the one kind of wealth that does not shrink when you share it.

This is why ego-less and valuable are not opposites. The ego clings; the skill has no need to. You can give everything away, the code, the design, the method, and keep the only thing that was ever really yours, which is the practised ability to do it again, and to do it better next time.

Make it structural

Here is the part I have come to believe is the real point. An ethic that lives only in your attitude evaporates the day you leave. The deepest form of ego-less development is not a feeling. It is a property of the system.

You can build the generosity in. Put the logic in libraries so it can be deployed a dozen ways. Keep the contract stable so the surface can change without a rewrite. Make the behaviour portable so it runs in more than one place. Write the tests so they are the executable specification, the thing that lets a stranger change the code without fear and lets the system survive the loss of its authors. Keep nothing load-bearing in your head.

Do that, and your dispensability stops being a promise you have to keep and becomes a fact about the architecture. The system does not depend on anyone continuing to feel generous, because the generosity is encoded. An attitude can be revoked. A design property persists.

This is also, not incidentally, how software becomes durable institutional property rather than one person’s project. A system that can pass between teams in a reorganisation and keep going is worth more than one that cannot, to everyone except the person whose job security depended on it being otherwise.

The highest form of care

I think the highest form of care for a piece of software is to build it so that it no longer needs you. Not so that you are unappreciated, but so that the thing you made can outlive your involvement in it.

It helps to zoom out. Your time on any system is one tenure among many. The code will pass through hands you will never meet, in an organisation that will restructure around it more than once, long after anyone recalls who wrote the first version. Seen from that height, the question of whose name is on it goes quiet, and a better one takes its place: will it still work when you are not there to explain it?

It runs against a lot of what the industry rewards, the hero, the firefighter, the one irreplaceable person. But those are roles that keep systems fragile and people anxious. The quieter path, ego-less, stoic, generous, builds things that last and leaves you lighter. You stop carrying the weight of being necessary. You get to do good work, give it away, and walk on.

“Design for your own departure. It is the most useful thing you will ever build.”