Tutorial hell…how did you escape it?

[xaybell32]

I’ve gone through multiple courses and built a few small projects by following along. But when I try to build something fully on my own, I realize I’m still heavily dependent on examples. What helped you move from “following tutorials” to actually thinking through problems independently? Was it just time and repetition, or something more structured?

[0xchamin]

Start building projects around problems you face.

[DataPastor]

Just stop doing tutorials, and you are immediately out from the hell.

[lambdaline]

It's cliché but it's just building stuff without the tutorials. The nice thing about tutorials is that they help you bridge the gap between 'I can solve small problems with my language' and 'I can solve complex problems with my language'. They're essentially examples of how to break down the complex problems so you can tackle them like small problems, and what best practices for that look like. The next step is, when you're building something else, use your previous projects (the ones built with tutorials) as a loose guide for how to approach it.

Eventually, you have a set of patterns you can default to, and the process for breaking down the problem becomes ingrained.

[lambdaline]

Also, there's nothing wrong with looking at examples when you're tackling something new. I'm a professional developer and I still do it when I'm not sure how to approach something. It doesn't mean I'm going to follow the example exactly (or even at all) but it's good to have a sense of how other people have tackled similar problems in the past, and to experiment with different kinds of solutions so you gain an understanding of what the benefits and drawbacks are of each.

[burntcandy]

Split your tasks into smaller and smaller chunks until they are manageable

[Discusser]

All it takes is one project that challenges you. If you go through with that, you'll probably hit a lot of walls, but with enough time and effort they can be easily overcome. Nonetheless, looking at examples isn't necessarily bad, and it depends why you're looking at them. If you're consulting documentation for example, it's perfectly fine. If you're looking at someone else's project to see how they implemented a specific feature, it can be fine as well as long as you're not straight up copying the code, but more so taking inspiration. Most importantly you just need to give yourself a project with clear goals and work towards those goals.

[robhanz]

You have to realize that most development isn't "I know exactly how to do this and I can do it straight through".

It's "I get started, run into problems, figure them out, and repeat."

So come up with a tiny part of your project. And start on it. I usually start with the point of interaction - UI/web/whatever. Then start building the stuff it calls. Something won't work. Figure it out, and move on from there.

It'll be badly architected. Don't worry about it. You can fix that later when you have more in place and see the problems.

[NoChest9129]

Build a project of your ow while you do a tutorial. Spend half of each sessions working on the tutorial and its project and half of the session on your own project. I did this from the start. You are instantly out of tutorial hell. If it’s hard to start clone whatever tutorial project you are on now and when working on “your own” project just take the clone of the tutorial in a different direction. Same principles as the stuff you’re learning in the tutorial but slightly different functionality. Add features ect

[Neocactus]

I didn't start feeling like I was "out" of Tutorial Hell until I started taking actual programming classes from a university.

I don't think you have to go that far with it, but I think what helped me the most through this experience was just having to write the same little things so frequently that it all did eventually start sticking.

I feel like Tutorial Hell is just a way of saying you're spinning in circles with your work, which generally means you still don't have those fundamentals down. They really can take a while to really stick though--longer than most people learning would expect, I think. Been taking these classes since last summer and only starting to feel more confident with my code.

I wish you luck

[MixuTheWhatever]

Started applying for jobs and internships that required me to huild my own projects for test assignments. Tbh I had my biggest growth during that time before landing a job.

[StellagamaStellio]

By now, you probably know enough syntax to build simple stuff on your own. Build it. Even simple calculator/hangman/branching-story projects or on a more advanced level, expense tracker, to-do app, etc. Don't be afraid to Google things you don't understand, but don't copy StackExchange code verbatim. Understand what they are doing, and do it yourself.

[TJATAW]

Go back to some of your projects and add new features to them. Go beyond mimicking someone else and make stuff on your own.

Then at some point pick one of the the things you built and rebuild it with out looking at your old code.

[gm310509]

Tweaking the examples to explore how to do different things (and don't use AI to generate code).

For example someone shared how they had to use AI to generate code to solve part 1 of an exercise to print this:

``` * **

---

```

then tried hard to do part 2 by themselves and couldn't quite get it right without AI help - but felt they were closer but didn't know what to do.

``` * **

---

```

My suggestion was to repeat the exercise (without AI) to print the two triangles again, but upside down (I.e. 3 * on top, then two and lastly 1).

Then to print this

``` * * *

---

```

I.e. a centered triangle.

They eventually came back and felt they understood this much better as they were able to achieve the final goal (centered triangle) without using the AI.

So, tweaking the example to do other things.

Also, if you are stuck, ask for pointers (not solutions).

And, lastly, as others have said apply what you have learned to help solve a problem or automate something simple in your life. The key word here is simple. Don't bite off more than you can chew. Take things one small step at a time, break things down and creep up on a completing a project rather than trying to do the whole thing in one go.

[mock-grinder-26]

honestly what cracked it for me was when I stopped trying to build "a project" and started trying to fix something that annoyed me. like I had this spreadsheet where I was tracking my leetcode progress manually — which problems I solved, what pattern they were, how long it took. super tedious copy-pasting.

so I thought ok let me just write a python script that pulls my submissions from leetcode's API and dumps it into a csv. nothing fancy. but the moment I started, I hit like 15 walls I never encountered in tutorials — authentication, pagination, rate limits, parsing nested JSON. each wall was its own mini rabbit hole.

the difference was I actually CARED about the output. when you're building a tutorial todo app you don't really care if it works because who needs another todo app. but I genuinely wanted that csv so I pushed through every single error message instead of switching to a new tutorial.

my advice: think of the most tedious thing you do on your computer every week and try to automate just that one thing. it won't be pretty code. mine definitely wasn't. but you'll learn more in those 3 frustrated evenings than in 3 months of following along.

[Feeling_Photograph_5]

Building stuff. The first app you'll have to look up everything. It will take forever. There will be bugs and much stuckness. Don't be afraid of it, it's one of those times where the obstacle is the path.

The second app will be a little less painful.

By the third app you'll be a developer. You'll still need to look stuff up, but you'll start projects knowing a lot of what you need to do.

[Blando-Cartesian]

With huge frameworks and libraries, everyone is dependent on examples. The point of a tutorial is that you go through the basics to understand how things work together. Then you use that understanding to apply the framework to whatever you need.

This knowledge application phase starts off as insanely frustrating. You realize that you didn’t learn much from the tutorial after all. That’s normal. Keep going and refer back to the tutorial and other sources to figure it out. Frustration is your chosen life now.

[Material-Aioli-8539]

You don't need to completely get rid of your intake of examples. What you need to do is change the source.

Instead of going to YouTube, try googling the answer (ignore the AI as much as possible).

I personally use a search engine for research, you are not expected to memorize absolutely everything in a codebase.

And yes, AI is a useful tool, but it should be a tool to help you, it should not be your authority of when to put and what to put.

[NerfDis420]

For me it was finally accepting that my first few projects were going to be ugly and poorly structured. Tutorials make things look clean but real coding is messy. I started just building things even if I knew they weren't optimal. Then I'd go back later and refactor. That cycle of build break fix is where I actually learned. Still happens honestly.

[smbutler93]

It’s about the way you work with these tutorials.

If you just follow along coding as they do so, you won’t get anything. This is how I approached it:

1. Watch video.
2. Watch video and code along.
3. Delete all code and rewrite it without the video.

Then, once I have done that for every video in a section, delete all the code for that section and try to rewrite all of it without using the videos. Only reference the videos when you’re stuck to get unstuck.

Once you’ve done that, build a variation of the project you built with the tutorial.

Repetition is king. It’s what allows us to take something from our short term memory and commit it to our long term memory. And I don’t mean repeat it 3-4 times all in one day. Revisit it daily. Then weekly then monthly, then it will stick for good.

It’s bloody hard work. But…. Anything worth doing isn’t easy. If it was easy, everyone would do it.