Skip to content
woza.ink
← Blog
3 min read

Why I Build Things

#personal#career#motivation

Reflections on why building small projects keeps me sane and sharp as a developer.

On this page
  1. The Hook: Why side projects beat passive learning
  2. How I treat side projects (a practical playbook)
  3. What I learn (and what compounds)
  4. The joy of shipping
  5. Not about money (usually)
  6. The short version

One line: I build things because making tiny, imperfect stuff is the fastest path from "idea" to "I know something now."
Subtitle: less theory, more chaos. More shipping, fewer meetings. ✨

⚡ Pro tip: if you can finish it in a weekend, you're learning faster than if you read three docs and never touch the keyboard.

The Hook: Why side projects beat passive learning

At work I solve other people's constraints. Side projects are where I break rules, try new tools, and learn how things actually fail in the wild1. It's like a low-stakes lab for curiosity.

  • Work gives you requirements, budgets, and legacy code.
  • Side projects give you permission to be weird, to refactor with abandon, and to throw away things that don't work2.

Yes, sometimes they fail. Good. Failure is feedback served quickly — the most honest kind.

NOTE: Shipping is a pressure test. A todo app that sits on your laptop is a draft. A todo app that other humans actually click is a mirror.

How I treat side projects (a practical playbook)

  1. Start tiny. One feature. One goal. One weekend.
  2. Pick a friction-reducing stack (something you already grok).
  3. Ship the core, then iterate. Release > perfect.3
  4. Keep the scope mercilessly small — scope creep is the silent productivity killer4.
  5. Learn, log, move on. Every project should teach one concrete thing (auth patterns, DB migrations, UX fail cases).

I use tiny experiments to test ideas: a two-hour prototype, a weekend MVP, then either a polish pass or a graceful sunset. The iteration rhythm matters more than the idea quality.

What I learn (and what compounds)

Each project teaches a micro-skill: state management patterns, deployment gotchas, API ergonomics, or the mental model behind a library. These micro-skills compound — they make the next project faster and better5. It’s not just knowledge accumulation, it’s muscle memory.

Pull-quote: "Small projects are compound interest for craftsmanship."

The joy of shipping

There’s a real, weird joy in sending an update and watching one or two strangers use it. Shipping makes learning visible. It transforms private experiments into public signals.6

Not about money (usually)

Monetization shifts intentions. Most of my side projects are intentionally non-commercial — they’re playgrounds, not startups7. That freedom allows bolder choices.

The short version

  • Ship over polish. Try > theorize.
  • Start tiny: one feature, one weekend.
  • Learn one thing per project. Make it explicit.
  • Keep scope small — scope kills experiments.
  • Fail fast, log lessons, move on.
  • If you want to build: start today and publish something imperfect.

If you build something, ping me. I love seeing experiments — drop a link, a weird bug, or a screenshot. Let’s trade notes and ship more weird, useful things. 🙌

— If you're curious about what I learned building Pomo, FitLog, or other small weirdos, check the rest of the blog. Or just start building. The rest follows.

Notes

  1. 1Quote

    "You mostly learn hacking by hacking." Paul Graham has consistently argued that the best way to learn is by building — original ideas don't come from trying to have original ideas, they come from trying to build or understand something slightly too difficult.

    — Paul Graham

    source →
  2. 2Source

    A 2019 study published in PNAS found that students in active-learning classrooms learned more than those in traditional lectures — but perceived they learned less. The comfort of passive listening creates an illusion of understanding. Doing the work feels harder precisely because it forces real engagement.

    — Deslauriers et al., PNAS 2019

    source →
  3. 3Quote

    "I actually ship products." Pieter Levels set out to launch 12 startups in 12 months — not to succeed at all of them, but to force himself to learn by finishing. His philosophy: the first version of anything always sucks, but with iteration it becomes something. The world doesn't end if something flops.

    — Pieter Levels

    source →
  4. 4Quote

    "Break the big thing into smaller things. The smaller it is, the easier it is to estimate." DHH built both Basecamp and Ruby on Rails as side projects. His shipping principle: either you ship or you die. Keeping scope flexible and focusing on running software matters more than planning.

    — David Heinemeier Hansson, *Rework*

    source →
  5. 5Context

    Mathematician Richard Hamming observed: "Knowledge and productivity are like compound interest. Given two people of approximately the same ability and one person who works ten percent more than the other, the latter will more than twice outproduce the former." The more you know, the more you learn; the more you learn, the more you can do.

    — Richard Hamming, *You and Your Research* (1986)

    source →
  6. 6Note

    Pieter Levels describes how he "hit publish again and again, learning on the fly." The act of shipping transforms private experiments into public accountability. Building in public — sharing progress, failures, and lessons — creates a feedback loop that accelerates learning far beyond solo tinkering.

    — Pieter Levels

    source →
  7. 7Quote

    "I'm proud of being used as an example for people who wish to bootstrap, become profitable, stay small, or any of the other motivations for being in business that have little commercial and industrial backing." DHH has long argued that a dent in the universe is plenty — you don't need venture capital or unicorn ambitions to build something meaningful.

    — David Heinemeier Hansson

    source →
↑ back to top