The best code I've written wasn't elegant. It shipped, it worked, and users never had to think about it.
Realising it in practice is even harder.
The thing they don't tell you in engineering
Early in a career, clever is how you prove yourself. You find the abstraction nobody else saw. You write the recursive function where everyone else wrote a loop. You architect the system that handles the case you're not even sure will ever happen.
It feels like craftsmanship. It's often something else.
Clever code is optimised for the moment of writing — satisfying to produce, impressive to show. But the person who reads it next, or the user who depends on it, has a different problem. They need it to work. Clearly. Reliably. Now.
What founding breaks open
I built a startup before I joined a software company. When you're a founder, you learn fast that the feedback loop is everything.
Ship late, and you don't find out if the idea works. Ship ugly, and you find out immediately. Ship clever, and you find out six months later when nobody can touch the codebase without breaking something.
The lesson isn't "write bad code." It's narrower: the elegance of code that never reaches users counts for very little.
When I was building at Umbr, I caught myself over-engineering an abstraction for a problem we hadn't hit yet. We were three people. The abstraction would have taken two days. We didn't have two days. I wrote the straightforward version in three hours. It worked. Users didn't care how it was built — they cared whether it worked.
That's the gap. Between clever engineering and useful engineering. The gap is: for whom?
What clever looks like in practice
Clever engineering is easy to recognise once you know what to look for:
- Abstractions that solve tomorrow's problems at the cost of today's readability
- Patterns chosen because they're interesting, not because they fit the problem
- Premature optimisation for scale you don't have
- Architecture that would impress in an interview but confuses a new teammate
- The "right" solution that ships three weeks after the "good enough" one
None of these are malicious. They come from good instincts applied at the wrong time. The instinct to generalise, to prepare, to do it properly — those instincts aren't wrong. The timing often is. YAGNI exists because this is a known failure mode. The list above is what it looks like in practice.
This is not an argument against quality
The easy version of this argument goes: "just ship fast and fix it later." That's not what I'm saying.
Sloppy code accumulates. Systems that are never refactored become systems that can't be changed. Teams that ship fast long-term tend to have clean foundations — because clean foundations let you move without fear.
The distinction isn't between quality and speed. It's between quality that serves users and quality that serves the author's sense of what good code looks like.
One of those has a feedback loop. The other doesn't.
The question I try to ask
One question cuts through most of the noise: does this solve a problem we actually have?
Not might have. Not could have at scale. Have, right now, with current users, on current load.
If the answer is no, the abstraction is a bet. Sometimes bets are worth making — you can see around a corner the team can't yet. But most of the time, you're borrowing complexity from the future to feel better in the present.
The follow-on: useful engineering defers complexity until complexity is the actual problem. It's not anti-craft. It's sequencing.
"For whom?" doesn't resolve every call. Every engineering decision has a version where the necessary complexity and the unnecessary complexity look identical from the inside. You're mid-PR, you're tired, you're confident in your model of the system — and the abstraction feels like it belongs. Sometimes it does. Sometimes you're three weeks ahead of the problem and don't know it yet.
What useful looks like
Useful engineering is harder to romanticise. It doesn't make a great war story.
It's the function that does one thing and does it clearly. The naming that doesn't require a comment. The system boundary that reflects how the business actually works, not how the textbook says it should work. The PR that a teammate can review in twenty minutes because it's doing what it says it's doing.
Useful engineering is also the decision to not refactor the working thing when the new feature is waiting. It's knowing the difference between technical debt that will bite you and technical debt that's actually just a reasonable trade-off given what you know today.
The craft is real. It just serves a different master.
Where I am with it
I understand the gap. I can name it, describe it, and recognise it in other people's code faster than I can catch it in my own.
Actually drawing the line — in a PR review at 6pm on a Friday, or mid-feature when the deadline is real — is something I still get wrong. The gap between understanding a principle and applying it under pressure is its own gap. A smaller one, hopefully. But it doesn't close.
What's changed is that I know it's necessary. The complexity that makes a system maintainable isn't optional — it's what lets the team keep shipping. But that complexity has to earn its place. It has to solve something real. And every time I'm about to add it, the question I try to hold onto is the same one: for whom?
I don't always have a clean answer. But asking the question is better than not asking it.