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.
/principles · 10 statements
How I lead, how I write code
Not rules. The things I catch myself saying twice in the same week. If yours are different, mine are wrong for you.
01 02 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.
03 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.
04 Ship first, optimise on data
Optimising without data is animated guessing. Working thing first, profiler second.
05 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.
06 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.
07 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.
08 Listen longer than you speak
Weekly 1:1s. When I listen more than I talk, half of the 'unsolved' issues solve themselves.
09 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.