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.


  1. 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.

  2. 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.

  3. 03

    Decide what to build before you worry about how. Clarity about the goal is worth more than cleverness in the details.

  4. 04

    Prove it with tests. A system you can't measure is a system you can't trust, and one you can't improve.

  5. 05

    Build it so it works, then leave it clean for the next person. Code is read far more often than it's written.

  6. 06

    Keep the feedback loop short. Tighter loops make better systems and saner engineers.

  7. 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.

  8. 08

    Reach for new tools with judgment, not appetite. Understand a technique before you adopt it; understand it twice if it's fashionable.

  9. 09

    Scope small and finish. Most projects fail by trying to do too much at once.

  10. 10

    Modernize without breaking things. You renovate the house while the family is still living in it.

  11. 11

    Grow the people around you. The best engineers tend to grow themselves once given a problem worth caring about.

  12. 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.