Writing Code That Lasts

Most code is written once and read a hundred times. The economics are clear: optimize for reading. But most developers optimize for writing — they prioritize speed of initial implementation over clarity of the final result.

Naming is the most important optimization. A well-named function doesn't need a comment. A poorly-named one confuses every reader forever. I spend more time on names than on any other aspect of code. If I can't find a good name, I probably don't understand the concept well enough.

Abstractions should be extracted, not invented. Don't build an abstraction because you think you'll need it later. Build it when you see the same pattern for the third time. The first two implementations tell you what the abstraction should look like. The third one confirms it.

Tests are the specification. If a behavior isn't tested, it doesn't exist — or worse, it exists but nobody knows what it's supposed to do. I write tests that describe the contract: given this input, expect this output. When a test fails, it tells you exactly which contract was violated.

Leave it better. Every time I touch a file, I leave it slightly better than I found it. Fix the typo. Rename the confusing variable. Add the missing test. These micro-improvements compound — a codebase that's constantly being polished never needs a rewrite.

The best code I've ever written is code that another developer can read six months later and understand immediately. That's the only metric that matters.