Skip to content

WritingNote · · 1 min read

Robust, not elaborate

Two ways to get software wrong that look like opposites, and the skill of telling them apart.

I care a lot about foundations. Code that's easy to change, patterns the next person can follow without asking, a structure that will still make sense when the product is three times bigger. When I leave a project, I want it to be in better shape than I found it.

I care just as much about not overdoing it. Most software lives inside a business, and businesses need to move fast and change their minds. Complexity you add for a future that might never arrive is a cost you pay every day until it does — and usually long after it's clear it won't.

These look like opposite instincts. They're really one question asked in two places: is this load-bearing?

If it is — data models, the boundaries between systems, anything that's painful to undo — take the time and get it right. If it isn't, keep it simple, ship it, and let reality tell you where the weight actually goes.

Solid where it matters. Simple everywhere else. I'm still getting better at telling the two apart, which is probably the point.