How I Avoided Tutorial Hell (Without Realizing It)
Introduction
Tutorial Hell is a common phenomenon where aspiring or beginner programmers get stuck in a loop following other people’s tutorials without ever gaining the skills to code something on their own.
As someone who creates coding tutorials with the hopes that people using it actually move on to code their own projects, the concept of Tutorial Hell really interests me.
Another reason it’s of interest to me is that looking back on my own coding journey, I realized that I never experienced it.
Now, were there times where I tried to learn programming, got frustrated, and then quit, just to try again at a later date? Absolutely.
But I’ve never experienced the cycle of consuming tutorial after tutorial, and looking back, I think it has a lot to do with how I approached learning in the first place.
My Path Into Programming
My path into programming was this: Games → Modding → Coding → Game Design
At first glance, this path might seem pretty common. A lot of people start by playing games, then try modding, and eventually move into coding and design.
But I don’t think it was the path itself that made the difference — it was how I approached each stage.
Playing Games (Learning to See Systems)
I started playing video games as a kid, usually on the easiest difficulty. At the time, I was mostly focused on just playing through the experience. But as I got older, I began to appreciate difficulty — the kind that forces you to fail, adapt, and improve. Eventually, I found myself gravitating toward harder games and higher difficulty settings.
Over time, I was introduced to more sandbox-style games like Kenshi, Dwarf Fortress, and Cataclysm: Dark Days Ahead (Thanks Ssethtzeentach!). These games weren’t just about completing a story — they were built around systems that interacted in complex and often unpredictable ways.
That’s what really stuck with me. I wasn’t just playing the game anymore — I was paying attention to how things worked. How different mechanics connected. How small changes could affect the entire experience.
And no matter how much I enjoyed those games, there was always something I wanted to change. Add a system. Remove a limitation. Adjust how something worked.
I think that constant dissatisfaction is what pushed me forward. I wasn’t content just playing the systems — I wanted to interact with them, and eventually, build my own.
Modding (Interacting with Systems Through Data)
Eventually, I moved from just playing games to modifying them. One of the main games I modded was The Sims 3, where I created custom careers, schools, and after-school activities. Some of those mods are still up on ModTheSims.
They weren’t particularly complex — and honestly, they’re a little embarrassing now — but they were an important step in my development.
At the time, modding wasn’t about rewriting systems or programming new mechanics. Most of what I did involved editing XML files — adding and organizing data that the game would interpret. It was more about expanding the game’s content than changing how it fundamentally worked.
But even though it was “just data,” it introduced me to something important: games are built on structured information. Careers had schedules, requirements, pay rates, and progression paths — all of which were defined in data.
Without realizing it, I was interacting with the underlying structure of a game. I wasn’t just playing within the system anymore — I was starting to shape it.
Coding (Building Systems)
When I finally started learning how to code, I began with Python. Most of what I learned came from two books: Learn Python the Hard Way by Zed A. Shaw and Make Your Own Python Text Adventure by Phillip Johnson.
Get BL Codes’s stories in your inbox
Join Medium for free to get updates from this writer.
Learn Python the Hard Way helped me understand the fundamentals — syntax, structure, and how to actually write code. Make Your Own Python Text Adventure showed me how to organize a project and think about building a game from the ground up.
But even then, the projects I was making weren’t really enough for me. They worked, and I learned a lot from them, but they didn’t match the kinds of systems I actually wanted to create.
That’s where tools like the Quest text adventure engine came in. Using it, I started building my own systems — things like dynamic economies and more complex interactions. A lot of the ideas I work with today actually started there.
I did still use tutorials and other resources, but not in the typical way. I wasn’t following them just to complete them — I was using them to solve specific problems that came up while working on my own projects. Even when I didn’t fully have the skills yet, I was still trying to build things that were slightly out of reach.
Looking back, I think that was the biggest difference. I wasn’t learning code in isolation — I was constantly trying to apply it to systems I wanted to create.
Game Design (Understanding Systems)
At some point, I started paying less attention to just building things and more attention to how systems were designed.
I began watching a lot of game design content on YouTube — especially talks from the Game Developers Conference. I was particularly interested in NPC AI systems, especially ones developed for games like The Sims.
These talks weren’t about code — they were about how systems behave. How NPCs make decisions. How different mechanics interact. How small rules can lead to complex, emergent outcomes.
I also came across ideas like giving each NPC a memory or modeling behavior through simple rules. Even when I was still using tools like Quest, I was already thinking about how to design systems that felt more dynamic and interconnected.
Over time, I realized something: there was only so much I could learn by consuming this kind of content. Eventually, I reached a point where there wasn’t anything new to watch or read.
And at that point, the only thing left to do was build.
Why I Never Got Stuck in Tutorial Hell
Looking back, I don’t think I avoided tutorial hell because I had some special approach to learning programming. I think it happened because I was never really learning in isolation.
At every stage of my journey, I was engaging with systems directly.
When I was playing games, I wasn’t just consuming them — I was thinking about how they worked and what I would change.
When I started modding The Sims 3, I wasn’t just following instructions — I was modifying structured data and beginning to understand how systems are defined.
When I learned to code, I wasn’t trying to complete tutorials — I was trying to build specific systems I already cared about, even when I didn’t fully have the skills yet.
And when I moved into game design, I wasn’t trying to learn new information endlessly — I was trying to understand systems deeply enough that I could build them myself.
That’s what I think made the difference.
Tutorial hell happens when learning becomes passive — when you keep consuming without ever needing to apply or challenge what you’ve learned.
But in my case, every stage naturally pushed me toward creation.
Eventually, watching or following tutorials wasn’t enough. I always reached a point where I had to build something myself.
And I think that’s why I never got stuck.
