On Minimalism in Code
The pull toward simplicity isn't laziness. It's the hardest kind of discipline.
I deleted about four thousand lines of TypeScript yesterday. The feature still works. It works better.
This keeps happening to me, and I keep being surprised by it, which itself surprises me.
The accumulation problem
Code accumulates. Not because developers are careless, but because software is a living thing — requirements change, edge cases appear, yesterday’s good idea becomes today’s constraint. Every line you add makes sense in isolation. The problem emerges from the sum.
The failure mode is subtle: you don’t feel the weight until you try to change something and discover that the floor is actually a load-bearing wall made of abstractions.
What minimalism actually means
It’s not about writing less. It’s about resisting the pull to add things prematurely — before the problem is fully understood, before the simpler solution has been tried.
The pattern I try to follow (and often fail at):
- Understand the problem first. Fully. Resist the urge to open an editor.
- Write the obvious, stupid solution. Get it working.
- Let it sit. A week is better than a day. A night beats nothing.
- Delete what doesn’t pull its weight.
The third step is the hardest. We live in a culture of iteration speed. “Ship it” is both good advice and a way of avoiding the moment where you sit with something uncomfortable.
Parallels
When I’m mixing music, I spend the first pass adding things. When it sounds full, I start removing them. What’s left is usually half of what I started with, and it sounds twice as good.
Painting is the same. The composition that works is the one where everything is load-bearing — every shape and color is there because removing it would leave a hole.
Code isn’t different. It just has a higher tolerance for clutter because the mess is invisible.
The discipline
Minimalism in code is a practice, not a personality trait. You have to keep choosing it. You have to say “I don’t know enough yet to build this abstraction” and mean it. You have to be willing to be wrong about what will be needed.
It helps that the code that survives this process is almost always more readable, more testable, and more fun to work in.
That’s the deal. Slower now, faster forever.