Operating principles
Twelve things I've come to believe about building software, leading teams, and the way the work actually goes. I update them as I learn.
- 01
The technology is rarely the hard part. The hard part is fitting the work to the people, the constraints, and the time you actually have.
- 02
Be the steady hand. Teams move faster when someone is calm, clear, and dependable at the moments that count — that is the job, not a bonus.
- 03
Decide what to build before you worry about how. Clarity about the goal is worth more than cleverness in the details.
- 04
Prove it with tests. A system you can't measure is a system you can't trust, and one you can't improve.
- 05
Build it so it works, then leave it clean for the next person. Code is read far more often than it's written.
- 06
Keep the feedback loop short. Tighter loops make better systems and saner engineers.
- 07
With AI, the model is the easy part. The real work is the engineering around it — evaluation, observability, cost, and honest guardrails. Reasoning and language belong to the model; calculations, authorization, and money belong to deterministic code.
- 08
Reach for new tools with judgment, not appetite. Understand a technique before you adopt it; understand it twice if it's fashionable.
- 09
Scope small and finish. Most projects fail by trying to do too much at once.
- 10
Modernize without breaking things. You renovate the house while the family is still living in it.
- 11
Grow the people around you. The best engineers tend to grow themselves once given a problem worth caring about.
- 12
Stay curious and stay honest. The names of the tools change every decade; the questions underneath do not.
These are working notes, not commandments. If any of them resonate with the way you build software, we will probably get along.