The two most difficult things I have ever done in my life have been teaching myself JavaScript and finishing an Ultra Nightmare campaign in Doom Eternal. While I was initially certain these two endeavours would be as closely related to each other as Michelangelo’s David is to a Campechano taco, I was bewildered to find they are linked by a precise conceptual thread.
I am talking about tutorial hell.
Many if not most programmers eventually become familiar with ‘tutorial hell’. Shockingly, it works out that playing Doom Eternal did not actually teach me anything useful on how to get out of it.
You can’t shoot your way out of tutorial hell. But there are still things you can do.
Let me tell you about them. And also about Doom. I feel like Doom is going to matter.
What is tutorial hell?
Let’s start by defining our terms. Tutorial hell is a metaphysical space where beginner programmers are sometimes consigned as a punishment for flying too close to the sun of learning. It’s called ‘hell’ not because it’s full of red walls, platforms you’ve got to jump up on and random plasma rifle ammo crates, but because it has no natural end.
Tutorial hell is essentially a cycle, and thus something you’ll be stuck within indefinitely unless you succeed in breaking the cycle.
In short, this is how tutorial hell works:
Step 1 – You complete a coding tutorial and learn skill Y.
Step 2 – You try building something using skill Y, and you suddenly realize you are missing skill X and you have no idea what you’re doing.
Step 3 – You take a tutorial to learn skill X.
Step 4 – rinse, repeat as above.
Tutorial hell actually does have a sort of symmetry with the Doom games, in that the two things are defined by psychological outlooks which are the exact opposite of each other.
You see, tutorial hell often has to do with a lack of self-confidence. People go back to tutorials when they try to apply their knowledge and suddenly feel an attack of anxiety – an acute sense that in spite of all the practice they have done, they really have no idea what they are doing. They think that doing another tutorial will allay these insecurities, but this only pushes the problem to a later point in time.
The space marine in Doom is exactly the sort of guy who will never get stuck in tutorial hell (the irony of this sentence is not lost on me). His will is unbreakable. He does not know doubt. His famous green armor won’t help you – but whatever mental routine he does before he gets up in the morning ready to burn the world down, that could probably teach you a thing or two.
Why is tutorial hell so hard to get out of?
The reason I play Doom is that, unlike real life, it always makes me feel like I am making some sort of progress. Tutorials feed you the same illusion, which is what makes them seductive: you finish a coding tutorial about, say, SQL, and you think to yourself ‘Hey, I just learned something! I am now one step closer to my goal of being good with SQL.’
There is actually some truth to that, inasmuch as you spending your time doing tutorials is not a complete waste of time that you are guaranteed to regret on your deathbed (notoriously unlike me playing Doom on Ultra Nightmare).
Tutorials do teach new and worthwhile coding skills. But they also have an inherent ‘ceiling’ to the sort of skills you can learn. You can only go so high (or so deep, even if that clashes with the ceiling metaphor).
If you were studying programming through anything but tutorials, you’d see the truth of this pretty quickly. You’d have to research which libraries to use by yourself. You’d have to test your solution and then debug it. You’d have to handle unforeseen and unforeseeable problems.
All these things are part of a programmer’s job, but here’s the thing – if you’re doing a tutorial, somebody else did all of that for you.
It was whoever designed your tutorial who took care of the debugging, testing, etc. and then streamlined the whole process so you wouldn’t encounter these problems yourself. You therefore never even see the ‘ceiling’ and yet get all the sense of progression and accomplishment of a space marine shooting a rocket down the throat of a hell knight (this may not be the best analogy I have ever come up with*).
In other words, tutorial hell happens when you get used to learning by hand-holding, and can’t learn any other way – which inevitably leaves you stuck at an amateur level.
Fortunately, that very description also gives us a clue on the next bit – how to get out of tutorial hell.
Again, no shooting involved. Disappointing as that may be. Or not.
*That statement probably applies to the entire article.
Ok, now tell me how to get out
If you want to learn how to speak a language, at some point you have to switch off Duolingo, go out into the street and start interacting with the people in that language.
The same holds true for programming. You have to get out of the bell jar of tutorials and into the nitty-gritty of the work. How do you do that in practice?
Here are three steps I would recommend.
The first thing you have to do is build something of your own. If you did a tutorial learning how to make a simple game, then create a different game. You want to come up with something related to your latest tutorial, naturally, so that you will be using and refining some of the skills you picked up, yet different enough that you’re not just repeating the same exercises.
This time, however, all the things that can go wrong will go wrong – instead of being neutered in advance by the designer of the tutorial. And it will be up to you to figure out how to solve them. You’ll need to ask for help and Google a lot, but this time you’ll be doing this outside the framework of the tutorial, finding resources by yourself. And don’t feel bad about looking stuff up – you’ll still be Googling stuff even when you have a decade of experience in this line of work.
As you build something by yourself, you’ll probably have to start on my recommended step two – look up and read the official documentation for whatever programming language and/or technology you are using.
This too is part of every programmer’s job. Reading documentation will teach you a great deal about the tools you are using, but crucially, this time you’ll be doing a whole new type of mental exercise. Your brain is no longer being led through a tour, it is out in the wilderness and finding out things all by itself.
Finally, I would also recommend contributing to an Open Source project. You’ll have to start small, naturally, and take only the smallest part of whatever project you selected. You should also mentally prepare yourself to see your first pull requests consistently crash and burn.
All that being said, working on Open Source projects is a fabulous way to get some experience doing real programming work. It doesn’t just provide excellent, independent practice which teaches you self-reliance, it also rewards you with a sense of accomplishment. When you get something done, your work was useful and made a difference. It even looks good on your CV.
In short – build stuff, read stuff, work on Open Source stuff. And get yourself a BFG 9000 in case there’s trouble.
Final Thoughts
It’s kind of sad to me that if I complete a coding tutorial, I don’t hear a deep, raucous voice saying “And thus did the walker of shadow complete his path of learning to bring destruction unto the heathen hoarde”. Even absent this infernal shot of endorphines, however, there is value in coding tutorials. You just have to know how to use them right. Learning how to learn is an art in and of itself.
If there is any takeaway you get from this article, I hope it’s this – don’t give up on your learning path. Asking you to be as determined and unstoppable as the Doom Slayer may be a bit of a tall order, but at least have the attitude. Remember that the benefits you will get from learning to code are many and more, and if your current approach isn’t working, change something about it.
Being tactical about going forwards is a better response to trouble than just retreating – at least when you find yourself in hell. Whichever version of it that may be.
