These aren’t rules. They’re patterns I’ve noticed in my best work and habits I try to maintain. They change over time.

  • Build to understand. The fastest way to learn something is to build with it. Reading and watching only gets you so far. Hands-on work reveals the details that matter.

  • Write things down. If I didn’t write it down, I didn’t learn it. Writing forces clarity and creates a reference I can return to. This entire site exists because of this principle.

  • Start simple, stay simple. Complexity is easy to add and hard to remove. Begin with the simplest version that works, and only add complexity when there’s a clear reason.

  • Measure before optimising. Intuition about performance is frequently wrong. Measure first, then optimise the thing that actually matters. This applies to code, systems, and processes.

  • Prefer boring technology. New tools are exciting but carry unknown risks. Proven tools let you focus on the problem instead of the tooling. Choose new technology deliberately, not by default.

  • Make it work, make it right, make it fast. In that order. A working system you can improve is more valuable than a perfect system that doesn’t exist yet.

  • Share what you learn. Knowledge compounds when shared. Writing publicly forces me to think more carefully, and occasionally helps someone else avoid a mistake I already made.

  • Question defaults. Most configurations, workflows, and architectural choices were made by someone else for their context. Understand why a default exists before accepting it, and change it when your context is different.

  • Rest is productive. The best ideas arrive when I step away from the screen. Sustainable pace beats heroic effort every time.

  • Stay curious. The most interesting problems are at the edges of what I know. Following curiosity is how I find work that matters.