Edit wiki/learning/building-to-learn.md — Work Reflections

---
visibility: public-edit
---

# building to learn

learning by building, not by studying. why making things teaches faster than reading about things.

## the core principle

the best way to learn something is to build something with it. not read about it, not watch a tutorial, not take a course — build a real thing that forces you to confront the actual complexity.

this isn't just my opinion. it's what the learning science supports: [[the-testing-effect]] shows that retrieval and application beat passive review. building does both simultaneously.

## why tutorials fail

following a tutorial is not building. it's copying. the tutorial author already solved every problem, and you're just retracing their steps. you feel like you're learning because it's novel, but there's no struggle, no failed retrieval, no debugging, no "wait, why doesn't this work."

the moment the tutorial ends and you try to build something on your own, you discover how little you actually retained. the gap between "followed along successfully" and "can build from scratch" is enormous.

## the learning-by-building loop

what actually works:

1. have a thing you want to build
2. start building it with whatever you currently know
3. hit a wall — you don't know how to do the next thing
4. look up specifically what you need (not a full course, just the answer to your question)
5. implement it, probably badly
6. iterate until it works
7. now you actually know that thing, because you fought for it

the key insight: steps 3-6 are where all the learning happens. the struggle is the signal. see [[perseverance]] — the temptation to give up at step 3 and go back to comfortable studying is strong.

## how this applies to my work

[[vibe-coding]] with AI is an interesting case. AI lets you skip steps 3-6 by generating code for you. this is great for productivity but potentially terrible for learning. the friction that AI removes is exactly the friction that produces understanding.

my current approach: use AI for things i already understand (speed boost) and build manually for things i'm trying to learn (learning boost). the danger is using AI for everything and ending up as a manager of code i don't understand.

this connects to [[critical-path]] — sometimes the critical path is building fast (use AI). sometimes the critical path is building understanding (do it yourself). knowing which one you're on matters.

## the prototyping advantage

building something bad quickly teaches more than planning something perfect slowly. the prototype reveals what you actually don't know, which you can't discover by thinking about it. see [[startup-workflow]] — the lean methodology is basically building-to-learn applied to business.

## the role of documentation

writing about what you built — like these wiki pages — is a second pass of learning. the [[testing-effect|the-testing-effect]] again: retrieving what you learned and organizing it in writing consolidates the knowledge. building is the first pass (learning through doing), writing is the second pass (learning through explaining).

this is why i use [[research-workflow]] as a complement to building, not a replacement. reading and research fill in the theoretical gaps that pure building misses — the "why" behind the "how."