I used to be addicted to tutorials. Udemy courses bookmarked, YouTube playlists saved, "Learn X in 30 Days" tabs open everywhere. It felt like progress.

But tutorial hell is not learning. It's the illusion of learning.

You watch someone build a todo app for the fifth time. You nod along, you understand everything they say, you even type the code with them. It feels productive.

Then you close the tutorial and try to build something on your own. Blank screen. No idea where to start. The confidence disappears instantly.

Tutorial hell makes you a professional watcher, not a builder. You collect knowledge but never apply it. You mistake familiarity for understanding.

The real learning happens when you struggle. When you Google the error message. When you debug for an hour. When you build something messy that actually works.

Tutorials are useful for getting started, but they become a crutch if you never leave them. At some point, you have to close the video and just build.

I still watch tutorials, but now I code before watching, not during. I break things first, then learn why they broke.

Anyone else escaped tutorial hell?

  • Coding is a problem solving skill. If you don’t have a problem in your head, you can’t possibly trying to find solution to something doesn’t exist.

    When you draw blank. Thinking of daily where is a need. For example! Like! “I want to watch YouTube but can I watch video without opening YouTube app? How do I do that?” There! You have a problem! Go find the solution! Code it!

    Coding is also a craft. In that regard, it's not that different from carpentry or plumbing. One can absorb knowledge about it all they want, but there is only one way to get good at it: Coding. Doing the work.

  • I used to write tutorials. Not anymore. Why? Because of the reasons you give.

    The fastest learning comes from working on real-world projects.

    An added benefit is that the skills you learn fast are actually needed in the real world.

    So not only do you learn faster and what you learn is more valuable, you're also more motivated and it doesn't even feel boring or tedious.

  • tutorials are meant to help you understand the basics. What are variables, functions, loops, synchronous vs asynchronous, and so on a so forth. So when you are vibe coding, you can at least someone understand what the code is doing. It will also help you create better prompts and troubleshoot. How can you be good at vibe coding more than basic apps if you don't understand what you're asking it to create in the first place.

    I will say, people look at these Youtube videos and think they will be able to automatically start building once it clicked. Even before AI, i discovered stack overflow and the tutorial rabbit hole revealed, a lot of developers don't know everything. They have to search for solutions and read documentation.

  • For me, the awareness that I've arrived back in tutorial hell is an invitation to stop, rest, and then engage in the engineering process of planning before writing code.

    What's your control feedback loop?

    Tutorial hell can become the zen garden of changing small things, adding and improving small things, in ways that weren't discussed in the video walkthrough or implemented in the demo code.

    Knowing where you are going is the most important part of finding your way towards the destination. Tutorials point a way towards something, and you begin applying the knowledge when you choose to do something that the tutorial doesn't directly teach. The messy, break-in-one-place-debug-run-tinker-break-repeat cycle is the control feedback loop. And the destination may change after you've started, that's okay!

    When I'm tired of breaking things on my way towards teh destination, I'll go re-read the Codeless Code or the Jargon File Koans, or do something completely unrelated to give my brain some float time to digest and have space to reprocess the raw data I just ingested. Functioning capabilities are about finding your own ways of applying the methods, rather than simply an ability to accurately follow instructions.

    Think about what you want to build.

    You, personally, for your own use. Unless it's for work, in which case obviously align with team goals.

    Then, with that outcome in your mind, design (sketch?) the interface, plan how you'll handle individual inputs and necessary outputs for storage, and then figure out what parts you can borrow from other projects, and what parts you'll need to figure out how to do.

    Who knows, maybe you'll discover a new tutorial, or re-familiarize yourself with an old one.

    Nobody criticizes wizards for referencing their spellbooks, and what is programming if not silicon magic?

  • There is nothing wrong with books/tutorials/docs, but spend at least 80-90% of your time coding and the remaining time looking at resources.

    "I still watch tutorials, but now I code before watching, not during."

    This is a great tip.

    To be honest I have created several Udemy courses related to coding but I always suggest that students type the code, alter it and experiment and make the code their own by applying it in a project that interests them. There is not much point in passively watching videos.

    To

  • dopamine toward building stuff, increase your failure rate, take breaks

  • Funny thing is, I'm still in the mindset of, why bother with tutorials when I can ask the AI anything?

  • I think some fundamentals are important at inception.

    So if you start by planning the stack and initial 1st steps (which everyone should), I like to understand why that stack is being suggested.

    Sometimes just asking the LLM that exact question is enough, but other times you may want to know more and some theory helps.

    But thereafter absolutely, problem first, then find the solution. Watching 3 hours of things you may or may not need is pointless.

    I learnt to read the code while building. Not from a tutorial.

  • Every learning should start from fundamentals. Which means books. Plus there are free CS courses of Stanford, for example, on YouTube.

    P.S. Not sure what your post is doing in this sub.

    The older Stanford one was certainly interesting. 

  • First, just build. People say it all the time, but it’s true. Next, learn the concepts around building and maintaining what you want to build, and how to plan a project. PRD’s & MVP outlines are super critical, identifying what you need to implement and how you’ll accept payment, host, etc., all of this is more important than watching a tutorial. Spend time using things and reading README.md’s and developer docs goes way further than whatever you watch, because you’re going to fuck up. Always keep in mind to remember what you learned, including successes and failures per project.