DEV Community

Cover image for How to Get Out of Tutorial Hell (Without Quitting Tutorials)
Spartan Rich
Spartan Rich

Posted on

How to Get Out of Tutorial Hell (Without Quitting Tutorials)

The fourth time I started a "build a full-stack app with React and Node" course, I noticed something. I knew exactly what the instructor was going to type next. I could have narrated it. Then I closed the video, opened an empty folder, and couldn't get a project off the ground without going back to lesson three.

That's tutorial hell. You watch, you follow along, everything works, and none of it survives contact with a blank editor. If you've searched for "how to get out of tutorial hell" at 1am, this is what I wish someone had told me.

Tutorials aren't the problem

The standard advice is "stop watching tutorials and just build something." I think that's half right and mostly unhelpful. Good tutorials are a fast way to see how someone experienced puts things together. I still watch them.

The problem is how I was using them. Following along feels like learning because your code runs at the end. But the instructor made every decision. You just typed. Your brain never had to retrieve anything, and things you never retrieve don't stick.

So the fix isn't quitting tutorials. It's changing what you do around them.

Watch first, code later

I used to code along at 1x with the video, pausing constantly. Now I watch a section through without touching the keyboard, sometimes at 1.5x. Then I close the video and try to build that section from memory.

I get stuck. Every time. That's the useful part. Each place I get stuck is something I thought I understood and didn't. I write it down, check the video for just that bit, and close it again.

It's slower on day one. It's a lot faster by week three, because I'm not rewatching the whole course.

Change one thing, on purpose

If the tutorial builds a todo app, I build a reading list. If it uses Express, I try Fastify. If it stores things in an array, I put them in SQLite.

The change has to be small enough that I can still follow the lesson, but big enough that copying stops working. The moment the instructor's code doesn't fit my project is the moment I actually have to understand it.

Write down the decisions, not the code

My old notes were pages of code snippets. Useless. The code is in the repo, and in the video, and on GitHub.

What I write now is the reasoning. Why the auth check lives in middleware. Why the instructor reached for useReducer instead of three useState calls. Why the migration runs before the seed. One or two lines each, in my own words, with a timestamp so I can find the part of the video again.

Those notes are the bit that transfers to the next project. The specific code almost never does.

Build the ugly version alone

After a course, I give myself one small project that uses the same ideas and no video. A weekend, tops. It's always uglier than the tutorial version. It has bugs the instructor never had because they'd already hit them off camera.

That's fine. Debugging my own mess teaches me more than any lesson did, mostly because nobody's there to tell me the answer.

Review it before it fades

Here's the part I skipped for years. I'd finish a course, build a thing, feel great, and three months later I couldn't explain how JWT refresh tokens worked even though I'd "learned" it.

Memory doesn't care that you finished the course. It cares whether you came back. Spaced repetition is the boring, reliable fix: look at what you learned a day later, then a few days later, then a week, then a few weeks. Each review takes a minute or two because you almost remember it. I wrote a short guide on implementing the SM-2 spaced repetition algorithm in JavaScript if you want to see how the scheduling actually works under the hood.

Where Recl comes in

My real problem wasn't one course. It was the forty YouTube videos, the conference talks, the blog posts and the 60-second clips explaining one concept that I'd saved and never opened again. My "Watch later" playlist was a graveyard.

That's why I built Recl. You share a video, reel, podcast or article to it from your phone or the Chrome extension. Recl writes a summary of the key ideas, with timestamps for videos, files it under a topic, and brings those ideas back to you 1, 3, 7, 14, 30 and 60 days after you saved them.

Recl feed showing saved videos and articles sorted by topic

For tutorials, the timestamped summary is what I use most. I can jump straight to the section where the instructor explained the thing I got stuck on, instead of scrubbing through a two-hour video. And there's Ask, which lets you query your own saves, so "what did I save about refresh tokens?" pulls up the videos and posts I actually watched, with sources.

It won't build the project for you. You still have to close the video and get stuck. Recl just makes sure the stuff you worked out doesn't quietly disappear a month later.

What it looks like now

I still watch tutorials, probably as many as before. The difference is that each one ends with me building something without it, a few lines of notes about why, and a reminder to look at those notes again next week.

The blank editor still scares me a little. But now I usually know what to type first.


I'm Spartan Rich, and I build Recl, an AI learning app that saves your videos, reels, podcasts and articles, summarizes them, sorts them into topics, and uses spaced repetition so you remember what you learned.

Top comments (0)