--- title: "Learn by Building: Why Makers Learn Faster Than Students" description: "The most effective way to master a technology isn't reading docs or watching tutorials, it's shipping something real. Here's the case for learning by building." date: 2026-03-14 url: https://valdemird.com/blog/building-to-learn/ lang: en tags: ["learning", "maker", "productivity", "career"] --- # Learn by Building: Why Makers Learn Faster Than Students > The most effective way to master a technology isn't reading docs or watching tutorials, it's shipping something real. Here's the case for learning by building. I've watched developers spend months on courses, tutorials, and documentation and still feel unprepared to build something real. I've also watched developers with half the "study time" ship production apps that actually work. The difference isn't talent. It's method. **Builders learn faster than students.** Not because building is harder, but because it forces a fundamentally different relationship with knowledge. ## The Tutorial Trap Tutorials feel productive. You follow along, everything works, you understand each step. But there's a hidden cost: you're learning the *instructor's* decisions, not making your own. *(Sources: [Freeman et al., PNAS 2014](https://www.pnas.org/doi/abs/10.1073/pnas.1319030111); [Engageli Active Learning Statistics 2026](https://www.engageli.com/blog/active-learning-statistics-2025))* More recently, a [2024 randomized trial with medical students](https://link.springer.com/article/10.1007/s40670-024-02219-1) confirmed the pattern: students scored **0.27 standard deviations higher** after active learning sessions. The evidence keeps piling up — hands-on engagement beats passive absorption, and tutorials *feel* productive without *being* productive. Nobel laureate Richard Feynman formalized this insight into what's now known as the [Feynman Technique](https://fs.blog/feynman-technique/): if you can't explain something simply, you don't truly understand it. Teaching forces you to close the gap between "I get it" and "I can explain it." When you ship a project, you demonstrate: - **Architecture decisions**: you chose a database, a framework, a deployment strategy - **Trade-off thinking**: you weighed options and picked one (this is the most valuable skill in senior engineering) - **Finishing ability**: most developers start projects; few finish them After interviewing 100+ engineers, the pattern is clear: the strongest candidates aren't the ones with the most certifications. They're the ones who can explain *why* they made specific technical decisions in their projects. "I used Prisma instead of raw SQL because the team was small and move-fast mattered more than query optimization" tells me more than "I have 5 years of database experience." A shipped project with real decisions beats a resume of technologies listed. ## The Compound Effect of Building in Public There's a compounding effect that most people miss. When you build and share publicly: 1. **You learn the thing** (by building it) 2. **You solidify the knowledge** (by writing about it) 3. **You get feedback** (from people who read your post) 4. **You discover gaps** (questions you can't answer yet) 5. **You fill those gaps in the next project** (the cycle repeats) Each project makes the next one better. Not just technically. Your ability to *think about problems* improves. You develop intuition that no tutorial can teach. You don't need to invent a new framework. Build a todo app, but make it *yours*. Choose the tech stack, design the UI, make the hard decisions. A well-executed familiar idea teaches more than an abandoned ambitious one. ## How to Start The biggest barrier isn't skill — it's perfectionism. Here's the antidote: 1. **Pick a problem you actually have.** Don't build a "practice project." Build something you'll use. The motivation to finish is 10x higher when you're your own user. 2. **Constrain the scope ruthlessly.** The first version should take a weekend, not a month. Ship the embarrassing MVP. You can always iterate. 3. **Write one thing about it.** A blog post, a tweet thread, a README with actual decision explanations. Teaching is the multiplier. 4. **Ship it.** Deploy it somewhere real. A project on localhost is a draft. A project with a URL is a product. ``` Weekend 1: Build the core feature. Deploy it. Weekend 2: Fix the top 3 things that bother you. Weekend 3: Write about what you learned. Repeat with the next idea. ``` ## The Knowledge You Can't Google There's a type of engineering knowledge that doesn't exist in documentation. It lives in the gap between "I know how X works" and "I know what happens when X meets Y in production." Michael Polanyi called this [tacit knowledge](https://en.wikipedia.org/wiki/Tacit_knowledge), the kind of knowing you can only acquire through experience, not instruction. You can't read your way to this knowledge. You can only build your way there. > "What I cannot create, I do not understand." — Richard Feynman (written on his blackboard at the time of his death, 1988) Stop preparing. Start building. The learning follows. --- **Further reading:** - [Active learning increases student performance in STEM](https://www.pnas.org/doi/abs/10.1073/pnas.1319030111), Freeman et al., PNAS - [The Feynman Technique](https://fs.blog/feynman-technique/), Farnam Street - [Building Beyond the Job: Dev Side Projects in 2025](https://dev.to/matin676/building-beyond-the-job-dev-side-projects-in-2025-3meb), DEV Community - [New Research Shows Learning Is More Effective When Active](https://www.cmu.edu/news/stories/archives/2021/october/active-learning.html), Carnegie Mellon