Principles

  1. Small steps beat big promises

    Three finished projects beat five ambitious ones. The team remembers, and they trust the next thing I commit to a little more.

  2. The best doc is working code

    Code review is the cheapest documentation for the next engineer. The README doesn't open itself; the comment left in a diff outlives the README.

  3. I hire one well, not five fast

    Three hires so far. All three still here. If I hired fast that number would look very different.

  4. Ship first, optimise on data

    Optimising without data is animated guessing. Working thing first, profiler second.

  5. Three is a team

    Small-team habits should be set while the team is small. They're an order of magnitude harder to install later.

  6. Think three times before touching a second database

    Each new store is another on-call burden, another backup story, and one more system the next engineer has to learn.

  7. If Friday scares you, the system isn't ready

    If you can't deploy on a Friday at 5 PM, somewhere you already knew the system was stronger than you. That's a signal, not code.

  8. Listen longer than you speak

    Weekly 1:1s. When I listen more than I talk, half of the 'unsolved' issues solve themselves.

  9. Praise in public, debug in private

    Wins go in the channel, with names. Mistakes get walked through one-on-one, without an accusing tone. The person already knows; don't make them feel worse.

  10. Don't confuse motion with progress

    More meetings ≠ more work. More releases ≠ useful releases. A polite "no" is the highest-leverage tool in the kit.

Updated when something changes — not when a new framework lands.