Please wait...
There is a version of learning to code that feels productive but is not.
You open YouTube in the morning and find a tutorial and follow along line by line and three hours later you have watched someone else build a project. You took notes and paused and rewound and it felt like work. Then you close the tab and open a blank file and have no idea how to start.
That was me for a long time and it was not because I was lazy. I worked hard. I just did not know that following code somebody else wrote and writing your own from scratch are two different skills and only one of them makes you a developer. The first feels like learning and the second is learning. The gap between them cost me more time than I like to admit.
I started learning web development in 2021 on an old Intel HP desktop because I did not have a proper laptop yet. It was slow and heavy and always struggling to connect to the internet. A tutorial would freeze in the middle of a sentence and running basic HTML and CSS locally took longer than it should have.
Those conditions taught me something I did not know I was learning. When you fight for every tutorial you take none of it for granted. You pay attention differently and you work harder to hold onto what you just watched because rewatching means waiting for the page to load again. I was more patient then than I gave myself credit for, mostly because I had no choice.
I never quit. Not on the days the system froze three times in a row and not on the days I lost code I had not saved. I waited for it to restart and kept going.
Then my dad surprised me with a new laptop. I still think about that moment and not because of the laptop itself. The old desktop was about enduring. The new machine was the first time I felt I had real tools to go somewhere instead of just surviving the process of trying.
I jumped straight into JavaScript and React. Dave Gray is the person who made it click early on. What set his teaching apart was that he explained the reasoning behind things, like why certain patterns exist and what happens when you skip steps. I did not only learn what to type. I started learning how to think about what I was typing.
The developer community helped in a different way. I watched experienced developers share how they approach problems they have not seen before and how they debug and how they decide what to build next. Seeing someone work through something hard in public makes the difficulty feel normal in a way finished tutorials never do. Finished tutorials make everything look straightforward and real developers working on real problems look like what it really is.
But through all of this I was not building anything on my own.
My planning was excellent. In my head I had whole projects mapped out, with the layout and the animations and the user flow and how it would feel to use. It felt like productive thought and it was a version of coding without any of the coding. You finish a tutorial and feel capable and then open a blank file and feel lost. You plan a project and it feels almost built and then the blank file makes it feel impossible. Plenty of people stay in that loop for months. I know because I did.
It looks like being careful and thorough and waiting until you understand enough not to waste time building the wrong thing. What is really happening is that you are avoiding the discomfort of being visibly bad at something, and the only way out is to go be visibly bad at something.
Ideas do not develop in your head. They develop when you start building and hit the first problem you did not plan for. That problem is the lesson and everything before it is setup.
I started reaching out to developers who were further along and asking questions and really listening instead of collecting advice. One conversation gave me a line I kept coming back to for months.
That sounds obvious now. At the time it landed differently because reading and watching are comfortable and building is not. Building means getting stuck in ways you cannot Google your way out of in thirty seconds. Your first version looks nothing like what you imagined and you finish a project that is not what you planned and ship it anyway because done beats perfect and perfect never shows up.
Tutorials are comfortable because someone else does the hard parts in front of you. They handle the edge cases and debug the error before you see it and tell you when something is about to break. When you build alone you have an error message and a problem and yourself. That pressure is uncomfortable and it is also what builds the skill.
In June 2022 I stopped watching tutorials for a while and started building small things. A todo app and a clock and a calculator and a quiz app. None of them were impressive and none were what I would have built if I had waited until I felt ready. They worked and that mattered more than I expected. Each one taught me something no tutorial had.
The todo app taught me about state in a way watching someone else manage state never did. I spent three hours wondering why my list would not update when I added an item until I realized I was changing the array directly instead of making a new one. React saw the same array and had no reason to render again. Deciding where state lives in your own project and making your own mistakes and then understanding why they were mistakes is different from applying something someone explained. The React guide on updating arrays in state covers the why and it lands differently once you have hit the problem yourself.
The clock taught me about JavaScript timing and why it behaves strangely when you expect it 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 works according to the MDN page on setInterval. No tutorial covered that because tutorials cover the expected path and your own projects keep taking you off it.
The calculator showed me how quickly simple logic gets complicated once real input shows up. A calculator sounds basic until someone types something you did not account for or you add 0.1 + 0.2 and get 0.30000000000000004. Then you are handling edge cases from the IEEE 754 floating point standard that you never considered when you designed the thing in your head. It changed how I build because I stopped assuming people would use my work the way I expected.
The quiz app was the first project where I hit something I truly did not know how to do and had to work it out without a tutorial. I had to read documentation properly for the first time to learn how to handle race conditions with an AbortController and I mean read it and not skim it for code to copy. That is a different relationship with learning than following along and it is the one that transfers.
The moment you are stuck and nobody on screen is telling you what to type is where learning happens. You read the error and search for the specific problem you have instead of a tutorial topic and try something and it fails and you try something else and it works. You understand why because you lived it in your own code. That kind of understanding does not fade the way watched content does.
Debugging looked different after enough of this. Early on I treated errors as proof that something had gone wrong and later I treated them as information. An error message is your program telling you what it needs. Reading them instead of panicking is one of the more useful skills you can build and tutorials cannot teach it because they are designed to keep you away from errors.
Building small projects also made fundamentals feel like tools instead of prerequisites. Before the quiz app I thought JavaScript array methods were things to memorize and afterwards they were things I used to solve a problem I had run into. Fundamentals are not a course section you finish before the interesting part. They are what you return to every time you hit a wall and every framework and library sits on top of them. When you understand what they are built on a new tool takes days to learn instead of weeks.
I see beginners rush toward frameworks because frameworks feel like the destination. React does not make sense if the JavaScript execution model does not make sense and Next.js does not fully make sense if the React rendering model does not. You can skip steps and still build things but the gaps show up later when something breaks and you cannot explain why.
Something else shifted during that period. I stopped building just to have built something and started building because I wanted the thing to work properly for whoever used it. When you build to be done you optimize for done. When you care whether it works you start asking what breaks when someone does something unexpected and how it performs on a slow connection and what happens on a screen size you did not test. That is where engineering starts and for me it started over a few months of shipping things and putting them in front of real conditions and caring when they did not hold up.
I still run into bugs and hit walls and open documentation for things I have used a dozen times because I forgot a method name. That is how it works at every level. What changed is not that building got easy. I stopped reading difficulty as a sign I was not ready. You do not reach a point where things stop being hard. You reach a point where you trust yourself to figure out hard things, and that trust only comes from having done it before.
If you have been in tutorial mode for a while watching and reading and taking notes and feeling like you are learning without finishing anything, I am not here to make you feel bad about it. Most people go through that phase. It just should not 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 to feel manageable and real enough that you care if it works. A todo app or a weather widget or a clock or a form that validates input. It does not need to be original. It needs to be yours.
You will get stuck. Stay stuck long enough to figure it out before you go searching for someone who built the same thing. That discomfort is where the learning is.
The project does not need to impress anyone. It needs to work. Then you build another one and then a harder one and somewhere in there you stop feeling like someone who watches developers and start feeling like one.
I did not get good. I got unstuck and those are different things. Open a blank file today and build something small and a little bad and ship it.
I tried.
Last updated: October 14, 2026.