There's a version of learning to code that feels productive but isn't. You open YouTube in the morning, find a tutorial, follow along line by line, and three hours later you've watched someone else build a project. You've taken notes. You've paused and rewound. You feel like you did something.
Then you close the tab, open a blank file, and realize you have no idea how to start.
That was me for a long time. Not because I wasn't working hard. I was. I just didn't understand yet that following someone else's code and writing your own from scratch are two completely different skills, and only one of them actually makes you a developer. The first one feels like learning. The second one is learning. The gap between those two things cost me more time than I want to admit.
I started learning web development in 2021. Before I had a proper laptop, I was working on an old Intel HP desktop. Painfully slow, always struggling to connect to the internet, and heavy in the way machines from that era were. I'd be watching a tutorial and the system would freeze mid-sentence. Running basic HTML and CSS locally took longer than it should have. Everything about that setup was working against me.
But looking back, those conditions taught me something I didn't know I was learning. When you have to fight for every tutorial, you don't take any of it for granted. You pay attention differently. You try harder to hold onto what you just watched because rewatching it means waiting for the page to load again. I was more patient then than I gave myself credit for. I also had no choice but to be.
Those were frustrating days, but they built something in me. I never quit. Not once. Not even on the days when the system froze three times in a row or I lost code I hadn't saved. I just waited for it to restart and kept going.
Then my dad surprised me with a new laptop. I still think about that moment. Not because of the laptop itself but because of what it meant. The old desktop was about enduring. The new machine felt like the beginning of something real. It was the first time I felt like I had the actual tools to go somewhere, not just survive the process of trying.
I jumped straight into JavaScript and React. Dave Gray was the person who made it click early on. What made his teaching different wasn't just that it was clear. It was that he explained the reasoning behind things. Why certain patterns exist. What happens when you skip steps. That kind of thinking stuck with me in a way that pure syntax walkthroughs never did. I didn't just learn what to type. I started learning how to think about what I was typing.
The dev community helped in a different way. Watching experienced developers share things openly, not just code but how they approach problems they haven't seen before, how they debug, how they decide what to build next. I absorbed a lot of that without even realizing it at the time. There's something about seeing someone work through something hard in public that normalizes the difficulty in a way that finished tutorials don't. Finished tutorials make everything look straightforward. Real developers working through real problems look like what it actually is.
But here's what I wasn't doing during any of this. I wasn't building anything on my own.
My planning was excellent. In my head I had entire projects mapped out. The layout, the animations, the user flow, the features, how it would feel to use. I'd spend real time thinking through how something would look and work. It felt like productive thought. It wasn't. I was doing a version of coding without any of the actual coding.
The frustrating thing is that it mimics the feeling of progress without producing any of the results. You finish a tutorial and feel capable. You open a blank file and feel lost. You plan a project in your head and it feels almost built. You open a blank file and it feels impossible. That loop is where a lot of people stay for months, sometimes longer. I know because I was in it.
The hard truth about that phase is that it feels like you're being careful. Being thorough. Waiting until you understand enough to not waste your time building something wrong. But that's not what's happening. What's actually happening is that you're avoiding the discomfort of being visibly bad at something. And the only way out of that is to go be visibly bad at something.
Ideas don't develop in your head. They develop when you start building and hit the first problem you didn't plan for. That problem is the actual lesson. Everything before it is just setup.
I started reaching out to developers who were further along, asking questions, and actually listening to what they said instead of just collecting advice. One conversation gave me a line I kept coming back to for months after.
You can't read your way into becoming a developer. You have to build your way into it.
That sounds obvious in retrospect. At the time it hit differently, because reading and watching are comfortable and building is not. Building means getting stuck in ways you can't Google your way out of in thirty seconds. It means your first version of something looking nothing like what you imagined. It means finishing a project that isn't what you planned and shipping it anyway because done beats perfect, and perfect never actually shows up.
The comfort of watching tutorials is that someone else is doing the hard parts in front of you. They handle the edge cases. They debug the error before you even see it. They tell you when something is about to break. When you build on your own, none of that safety net is there. You just have the error message and the problem and yourself. And that pressure, as uncomfortable as it is, is exactly what builds the skill.
In June 2022 I made a decision. I stopped watching tutorials for a while and started building things. Small things. A to-do app. A clock. A calculator. A quiz app. None of them were impressive. None of them were what I would have built if I'd waited until I felt ready. But they worked. And that turned out to matter more than I expected.
Each small project taught me something specific that no tutorial had. The to-do app taught me about state in a way that watching someone else manage state never had. Actually deciding where state lives in your own project, with your own component structure, making your own mistakes and then understanding why they were mistakes, that experience is different. You're not applying something someone explained. You're discovering it by running into the problem yourself.
The clock taught me about JavaScript timing functions and why they behave strangely when you expect them not to. I spent a long time debugging why my clock was slightly off before I understood the difference between how I thought setInterval worked and how it actually works. No tutorial had covered that edge case because tutorials don't cover the edge cases you create on your own. They cover the expected path. Your real projects will take you off the expected path constantly.
The calculator was the one that showed me how quickly simple logic gets complicated when real input shows up. A calculator sounds basic until someone types something you didn't account for. Then you're handling a dozen edge cases you never considered when you designed the thing in your head. That experience changed how I think about building things. I stopped assuming users would use what I built the way I expected them to.
The quiz app was the first project where I hit something I genuinely didn't know how to do and had to figure it out without a tutorial walking me through it. I had to read documentation properly for the first time. Not skim it looking for the code I needed but actually read it to understand what I was working with. That's a different relationship with learning than following along, and it's the one that actually transfers.
The moment you're stuck and there's no one on screen telling you what to type is where real learning happens. You read the error. You search for the specific problem you're having, not a tutorial topic. You try something. It doesn't work. You try something else. It works. You understand why not because someone explained it but because you just experienced it in your own code on your own problem.
That kind of understanding sticks differently. It doesn't fade the way watched content does. Because you didn't watch it happen. You made it happen, and then you fixed it when it broke.
I also started to see debugging differently after enough of this. Early on I treated errors as signs that something had gone wrong. After a while I started treating them as information. An error message is your program telling you what it needs. Learning to read them instead of panic at them is one of the more useful things you can develop, and you only develop it by debugging real errors in your own code. You can't build that through a tutorial because tutorials are designed to minimize the errors you run into.
The thing that building small projects did that months of tutorials hadn't was make fundamentals feel like tools instead of prerequisites. Before I started building, JavaScript array methods felt like things I needed to memorize. After the quiz app, they felt like things I used to solve a real problem I ran into. That difference sounds small. It's not.
Fundamentals aren't a course section you complete before getting to the interesting part. They're the thing you keep coming back to every time you hit a wall. Every framework you'll ever use, every library, every abstraction someone else built, is sitting on top of these things. When you actually understand what they're built on, new tools take days to learn instead of weeks. When you don't, every new framework feels like starting over.
I keep seeing beginners rush toward frameworks because frameworks feel like the destination. They're not. They're conveniences built on top of things you need to understand first. React doesn't make sense if JavaScript's execution model doesn't make sense. Next.js doesn't fully make sense if React's rendering model doesn't make sense. You can skip steps and still build things. But the gaps show up later when something breaks in a way you can't explain.
Something else shifted during that period that I didn't expect. I stopped building things just to have built something and started building things because I wanted them to work properly for whoever used them. That sounds like a minor difference. It isn't.
When you build to have built something, you're optimizing for done. When you build because you care whether it actually works, you start thinking about how someone else uses it. What breaks when they do something unexpected. How it performs on a slower connection. What happens on a screen size you didn't test on. Those questions are where the real engineering starts, not in the tutorial, not in the planning stage, but in the act of actually trying to make something good.
That shift happened quietly over a few months of shipping things. Not over a course or a book. Over the process of putting things in front of real conditions and caring when they didn't hold up.
I still run into bugs. Still hit walls. Still open documentation on things I've used a dozen times because I've forgotten a specific method name. That's not embarrassing. That's just how this works at every level. The thing that changed isn't that building became easy. It's that I stopped interpreting difficulty as a sign that I wasn't ready.
You don't get to a point where things stop being hard. You get to a point where you trust yourself to figure out hard things. That trust only comes from having done it before. Watching someone else figure it out doesn't give you that. Doing it yourself does. Every time. Without exception.
If you've been in tutorial mode for a while, watching, reading, taking notes, feeling like you're learning but not finishing anything, this isn't about making you feel bad about that. That phase exists for a reason and most people go through it. It just shouldn't last as long as most people let it.
At some point you have to close the video and open a blank file. Start something small enough that it feels manageable but real enough that you care whether it works. Pick anything. A to-do app, a weather widget, a clock, a form that validates input. It doesn't need to be original. It just needs to be yours.
You'll get stuck. Stay stuck long enough to actually figure it out instead of immediately searching for someone who's built the same thing and can show you how. That discomfort is not a sign you should stop. It's where the learning is.
The project doesn't need to impress anyone. It needs to work. And then you build another one. And then you build a harder one. And somewhere in that process you stop feeling like someone who watches developers and start feeling like one.
That's the whole thing. Open a file. Start something. See what breaks.