September 10, 2026 · 1 min read
Writing Code That Lasts
A few principles I keep coming back to for building software that stays maintainable.
The code that survives isn't usually the cleverest — it's the code that the next person can read, change, and trust. Here are a few principles I keep returning to.
Optimize for the reader
Code is read far more often than it's written. A boring, obvious implementation that a teammate understands in ten seconds beats an elegant one that takes ten minutes.
Make the change easy, then make the easy change
When a change feels hard, that's information. Often the right first step is to refactor until the change you actually want becomes small and safe.
Push complexity down, not out
Deep modules with simple interfaces hide complexity from the rest of the system. A good interface lets callers ignore everything you had to think about to build it.
The best abstraction is one you can use correctly without reading its source.
Leave a trail
Tests, clear names, and a short note on why — not just what — are gifts to whoever debugs this at 2am, including future you.
That's the whole game: keep the system understandable as it grows.