4 Ways to Escape Tutorial Hell (How I Approach Tutorials)

For anyone just starting programming, a new game engine, or a new framework, tutorials are definitely great for learning the basics and fundamentals.

What we don't want is to get stuck in just following tutorials or courses and to never really apply anything that we learn, which is pretty much the definition of tutorial hell.

What we want is to get to a level of competence where we can just open up Visual Studio Code, a game engine, or whatever else and start building without being spoon fed every little step of the way.

What's real though is that no matter the experience of a developer, were always one Google search away from ending up in a tutorial, Stack Overflow, or whatever else, looking for answers.

So, the key is to have a good balance with tutorials and not become overly dependent on them.

When you really break it down, escaping or staying away from tutorial hell is all about applying the materials that you learn.

In addition to just learning the basic foundations, it's really all about creating a backlog and accumulating skills by solving challenges on your own that then serve as proof to help you confidently get started with building non-tutorial software.

//1. Add your Flare

I think the easiest way to start building up that confidence is to add a little feature on top of the tutorial software in the courses you've done or are still following.

When I wanted to take game development seriously for example, I went and bought the Unity Game Development in 24 Hours, Sams Teach Yourself book by Mike Geig.

This book taught me the basics of the Unity engine, but I really learned the most from the little exercises that it provided after each section.

Sometimes the exercises were super simple and related to a concept that I had just learned.

Sometimes it's a completely new feature such as a scoring system or something that it asks me to figure out and add onto the game I just created from the course.

So, for every tutorial software that you end up making, it would be a good rule to change a little something in it or completely add a small new feature on top of it before you at least hop onto another tutorial.

//2. Assign Yourself Homework

If the course doesn't already provide small problems for you to take on, it would then be in your best interest to come up with something to assign yourself.

That is if you're serious about breaking out or staying away from tutorial hell.

Once you have that homework for yourself, what I like to do is let my questions or whatever I get stuck at tell me what to do next.

I will research and Google my questions.

If that then leads to me finding out that I need to create a loop of some sort, then that's my next task.

If I don't quite know how to make a loop, I will search for that as well.

And on and on...

So, I break down the problems into a list of smaller problems.

I've recently applied this concept when I went through the first Brackey's Godot tutorial.

On top of the game that I ended up creating with it, I added a double jump and coyote time.

But, I started off not really knowing how to do it.

I had an idea of how to go about it, but I wasn't 100% sure so I read the GDScript documentation, Googled it, and broke down the problems into smaller tasks.

Now, as an alternative, what you could also do is to look for challenges online or to think about something simple that you could do to actually apply what you learn.

As examples:

• For testing your knowledge of the basic concepts of programming, you can easily do a quick search for small challenges to do in whatever language online
• For testing your knowledge of the basics of an art tool, you can start to practice by 3D modelling or creating sprites of a simple object around you

Why do this?

Because even though you probably end up in tutorials or forums looking for answers, it will still ultimately be up to you to get things done and working.

A lot of the time, none of the solutions you find online will just work by copy pasting it in your codebase.

You search for answers every time you get stuck and figure it out.

That's when you actually learn.

This also makes learning fun.

It creates a string of small wins.

It builds positive momentum.

As you accumulate skills, an original project idea may even come up for you to pursue that is based on the mix of skills you've gained.

But...

//3. Start Cloning Projects

When starting your first project, I would recommend to clone an existing project instead of trying to create an entirely original idea.

Cloning a project has benefits:

• It takes away the pressure of inventing something new
• It takes away excuses (we know the project can be done)
• It lets you focus on just building the replicated look and functionality of the already existing project

So, look for projects to replicate and plan on creating a minimum viable product (MVP) version of it. What this means is to plan on creating just a simplified version of the project you want to clone whilst still meeting the core functionalities.

As an example, here's one of my games called Roguesphere:

For a MVP version of this game, the features it could have to consider it complete would be:

• The physics set up to walk around a planet
• The ability to kill enemies by just making them disappear when touched (equal to throwing them)
• Making enemies shoot the player
• A health or timer system

Now, back to one of the previous points in the video, the mindset of approaching this project should be that it's just another list of small problems.

When I worked on this, I took each task and again broke them down into even smaller tasks.

I started slowly answering questions that I had on how to do things and let wherever I got stuck on to guide me on what to do next.

I went from there until I figured it out.

The skill of deconstructing challenges into smaller and manageable problems is a vital skill to have as a developer, so that's something we should always practice.

//4. Don't Completely Follow Tutorials

Now, here's my final tip for when you're actually doing a tutorial.

Don't follow the tutorial instructions exactly as they're given to you.

Change as much of the little nuance things from the tutorial as much as possible.

If the tutorial says to create a script file called character controller, name it player controller.

If it says to create a variable called health, you call it life points.

If it says to create a function named jump, you name it hop.

You get the point.

Why? Because this forces you to actually pay more attention and keep track of what's going on rather than just turning on auto-pilot and blindly following the instructions given to you.

You may also break things and cause bugs and that's actually what you want.

That applies to life in general too right? Every mistake in life is a learning opportunity.

It's just all perspective.

//Conclusion

All in all, applying what you learn from tutorials, cloning projects, and intentionally following tutorials are what helps build your confidence to start making your own projects.

Make cool things, not just learn how.

Learn to build then build to learn.

See you in tutorial heaven :)

— Renz

//Supporters

Special thank you shout out to the following ongoing generous supporters of my work, making a difference in the world and mine.

• Laura Milligan
• Jacob Huang
• Andrew Abrook
• Faiz Prasla
• Armaigne Rivero
• Joshua Ravasco