All entries

The Kind of Work You Only Notice When It's Missing

Engineering Philosophy · Software Design · Engineering Leadership

Marcus Aurelius wrote in Meditations: “Waste no more time arguing about what a good man should be. Be one.” He wasn’t talking about software. But the principle is the same. Stop performing the work. Just do it. The results speak for themselves, especially when no one notices them at all.

Software works the same way.

The best systems I’ve built are the ones nobody mentions. No one messages you to say “hey, the API response was fast today.” No one notices the deployment pipeline that hasn’t failed in eight months. No one thanks you for the abstraction that made the next feature take two hours instead of two weeks.

That silence is the point.

Meditations by Marcus Aurelius
A Philosophy of Software Design by John Ousterhout

I used to think good engineering meant cleverness. Elegant solutions, surprising patterns, the kind of code you show people. I don’t think that anymore. The longer I work, the more I believe good engineering is about removal. Removing complexity. Removing surprises. Removing the need for the next person to think about your decisions at all.

John Ousterhout puts it well in A Philosophy of Software Design: complexity is anything related to the structure of a system that makes it hard to understand and modify. Not complexity in the algorithmic sense. Complexity in the human sense. The kind that slows you down, that makes you afraid to change something, that makes a simple task feel heavy.

Every layer you add, every abstraction you create, every interface you design is either reducing that weight or adding to it. There’s no neutral. The code either helps the next person or it doesn’t.


I think about this constantly. When I name a function. When I decide where to draw a boundary between modules. When I choose what NOT to build.

The hardest part of this job isn’t writing code. It’s deciding what matters. It’s looking at a feature request and asking whether the system actually needs it, or whether we’re adding complexity because someone asked for it and it felt easier to say yes than to have the conversation about why it’s a bad idea.

The engineers I admire most aren’t the ones who ship the most. They’re the ones who ship the least while solving the most. They write less code. They delete more. They say “no” with conviction and “yes” with intention.


There’s a tension in this industry between visibility and value. Features get celebrated. Launches get announced. Somebody builds a flashy dashboard and it gets shared on Twitter. Meanwhile, the person who quietly refactored the auth module so it stops leaking sessions gets a thumbs up in a PR review and that’s it.

I don’t think this is a problem to solve. It’s a reality to accept. If you need the recognition to keep going, this kind of work will burn you out. But if you find satisfaction in the craft itself, in knowing that something works well because you made it work well, then the silence becomes the reward.

It’s a strange thing to care about. The invisible. The structural. The decisions that only matter because they prevent problems that never happen.

But that’s the work I want to do.

Musashi Miyamoto

Aurelius also wrote: “The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” In this industry, the majority optimizes for output. More features, more lines, more velocity. The sane path is quieter. Build less. Build right. Let the work disappear into the product until no one can tell it’s there.

The kind of work you only notice when it’s missing. That’s what I’m after.

Share