Discipline, elegance, and the engineer’s true work
“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
- Edsger W. Dijkstra
From Working Code to Lasting Code
Every engineer starts with the same pursuit, getting something to work. The first time a program runs end-to-end feels like victory. But over time, you discover that “working” is the easiest milestone, not the hardest.
The harder milestone is making code last. Code that looks fine on day one often turns into a liability by year two. It slows teams down, resists change, and compounds in cost with every new dependency. Complexity always carries interest and eventually it collects.
The AI Shift
Now we’re in a new era. Code is abundant. With AI, it’s trivial to generate scaffolding, boilerplate, or even entire modules in seconds. The old bottleneck of “how do we build this?” has been replaced with “what do we do with so much code?”
And here’s the trap, AI defaults to complexity. It gives you more layers, more edge cases, more completeness than you often need. Complexity is no longer the product of overengineering. It’s the new baseline.
Which means the engineer’s role has evolved, and it is more critical than ever, not to produce code, but to shape it.
The Work of Simplicity
Simplicity isn’t the absence of complexity, it’s the result of wrestling with it. Every line of code you keep is a line someone has to maintain, reason about, and extend. The hidden cost isn’t in writing, it’s in carrying.
AI can suggest endless variations, but only an engineer can decide which parts deserve to stay. And that decision, what to cut, what to merge, what to leave out, is what separates durable systems from fragile ones.
Why Less Scales
At small scale, complexity is survivable. At large scale, it’s fatal. Every dependency multiplies the surface area for bugs, security issues, and confusion. Every “extra” layer is another place for things to break in production.
The irony is that less code isn’t just easier to maintain, it’s the only way to grow. Teams that keep things lean move faster, onboard quicker, and debug with clarity. Teams that let complexity creep in end up spending more time untangling than building.
That’s why “less is more” isn’t an aesthetic choice. It’s a scaling strategy. It’s what allows systems and teams to survive the weight of time.
Reflection
Complexity comes for free. Simplicity does not.
For me, the shift from adding to refining is where engineering becomes craft. It’s the difference between code that merely works today and code that endures tomorrow.