I watched 40 hours of video courses to learn web development. I learned almost nothing from them.
The thing that actually worked was building a project I cared about, getting stuck, looking up what I needed, and building more. That's a known result in education research — active learning beats passive learning. But the course-industrial complex keeps selling the passive model because it's easier to produce and sell.
Here's a more honest approach.
Why Tutorials Fail
The problem with tutorial-first learning is the tutorial is doing the hard work.
When you follow a tutorial, you're not solving problems — you're transcribing solutions. The moment you close the tutorial and try to build something similar, you face a completely different cognitive task: coming up with the solution, not recognizing one.
Tutorial success also creates false confidence. You built a full-stack app following a tutorial! You cannot build a full-stack app. You can follow instructions that result in a full-stack app. These are different.
The Project-First Alternative
The alternative: decide what you want to build before you decide what to learn.
The project constraints what you need to know. Instead of "learn JavaScript fundamentals, then DOM manipulation, then async, then fetch, then React," you have "I need to show data from an API on a web page. What's the minimum I need to learn to do that?"
That question has a much shorter answer. And once you've answered it by building the thing, you know it in a way that tutorial-watchers don't.
A Concrete Structure
Step 1: Pick a project with a clear outcome
Not "learn React." Not "build a social media app." Those are too vague or too large. Good first projects:
- A CLI tool that does something you do manually now
- A personal dashboard that shows data you check in multiple places
- An automation for one repetitive task
The criteria: small enough to finish in a week, real enough to actually use afterward.
Step 2: Spec it before you look anything up
Write down what the project does in plain sentences. What inputs does it take? What outputs does it produce? What states can it be in? This forces you to understand the problem before you reach for solutions.
Step 3: Get stuck and look things up in that order
Build until you don't know how to proceed. Then search for the specific thing you don't know. Read enough to unblock yourself. Build more.
This is exactly how experienced developers work. The goal is to start working this way immediately.
Step 4: Use AI as a tutor, not a doer
When you're stuck, ask Claude to explain the concept rather than write the code. "How does async/await work in JavaScript?" produces learning. "Write an async function that fetches this data" produces a function you don't understand.
The discipline: read the explanation, close it, write the code yourself. If you can't, ask for clarification on the part you don't understand, not for the code.
Bad prompt: "Write a React component that fetches user data from an API"
Good prompt: "Explain how useEffect and fetch work together. I want to understand the pattern before I write it myself."
Step 5: Build the same thing again
After finishing a project, build something similar but slightly different. Second-build is when you actually internalize the patterns — because this time you've seen the problem before, you know what you're building toward, and the gaps in your understanding are smaller.
What to Do About Foundational Knowledge
There's a real counterargument: don't you need fundamentals first? Yes, but less than you think, and tutorials aren't the best way to get them.
When your project runs into a concept you need to understand deeply — closures, how HTTP works, the event loop — go deep on that specific thing. Read MDN, read a book chapter, read the spec if you can. But enter that learning from a problem, not from a curriculum.
The curriculum model front-loads knowledge you won't use for months and wonder why it doesn't stick. The project model teaches you exactly what you need when you need it, and it sticks because you needed it for something real.
The Honest Caveat
This approach is harder. Watching videos is comfortable. Getting stuck and building your way out is uncomfortable. The discomfort is the learning. There's no shortcut there.
But the developers who learn fastest are the ones who've accepted that discomfort and built a lot of small, real things. Not the ones with the most courses completed.