Back to Writing

Things I Believe

8 min read

A collection of principles that guide how I build, learn, and work. These aren't universal truths—they're beliefs shaped by my experience, failures, and what I've learned along the way.

Ship fast > perfect planning

  • Real feedback from users beats hypothetical feature discussions
  • Iteration reveals what planning never could
  • Working software is the best spec document

Build > study

  • You learn more from one shipped project than ten tutorial courses
  • The best documentation is code you've written and debugged yourself
  • Breaking things (and fixing them) builds intuition faster than reading

Simple solutions > clever code

  • Boring tech that works beats cutting-edge tech that might
  • Code is written once but read hundreds of times — optimize for clarity
  • Delete features and code aggressively — simplicity compounds

Demos > documentation

  • Show, don't tell — a working prototype communicates better than paragraphs
  • Interactive examples teach faster than written specs
  • Good code is self-documenting, great code has examples

Problems > technology

  • The best tech stack is the one that solves the user's problem
  • Framework enthusiasm fades, but solving real problems never does
  • Understanding the problem deeply > knowing every framework shallowly

Sharing accelerates growth

  • Writing clarifies thinking — publish your learnings, even if imperfect
  • Your "obvious" insight might be someone else's breakthrough

Constraints breed creativity

  • Limited time forces you to focus on what actually matters
  • Small budgets lead to innovative solutions
  • Removing options often reveals the best path forward

User experience beats feature count

  • One polished feature beats ten half-finished ones
  • Fast, reliable basics > slow, buggy advanced features
  • Users remember how it feels, not what it has

Ownership drives quality

  • When you own the outcome, you care about the details
  • End-to-end responsibility builds better engineers
  • "Not my problem" is the enemy of great products

Consistency > intensity

  • An hour every day beats marathon coding sessions once a month
  • Small daily improvements compound into mastery
  • Sustainable pace wins long-term races

These beliefs evolve as I learn and grow. Some might not resonate with you, and that's okay. What matters is that you find principles that guide your own work.