How to Escape Tutorial Hell

The best strategy to create a healthy relationship with tutorials

What is tutorial hell?

Tutorial hell is the place where happy developers go to die. It’s the never ending pit of books, courses and videos. Instead of working on a real-life project or a personal project, you keep following tutorials. It’s that place where you spend hours watching a tutorial, but then when you try on your own, you’re back to square one.

We’ve all been there, the point is not staying there.

How do I get out?

The best way is by asking questions. We might get a little philosophical, but asking questions will naturally reveal your blind spots, while also giving you the next step to take.

Instead of thinking in terms of “tutorials”, think in terms of “projects”. When learning a new technology or tool, visualize a project. Once you clearly define a project in your mind, think of it as an end goal, which will later be broken down into smaller pieces.

For example let’s say we want to analyze weather data with Python (the project can be about anything, but I’m a data guy so.. 🤷🏻). First we need to visualize how our analysis will look like and what will it answer. Then we start asking questions like:
— How do I install Python?
— How do I run it in VS Code?
— What is a package?
— How do I install Pandas?
— How do I import a CSV?

Not knowing the answers is part of the game. We’ll probably need to google or ask chat gpt about it. I can confidently say that, asking and building will give a much higher return than following tutorials.

Focus on small projects

When learning something we might get desperate to show off our skills, but at this point we’re barely learning to walk. We should focus on quantity rather than quality (only at this stage). Since things are still new to us, we gain much more by getting familiarized with the tools, rather than mastering them.

Focus on doing projects of around 100 lines of code. It could be more, it could be less. The size of the project doesn’t really matter. What matters most is that you start a project using what you’re learning, and finish it. You could work on a +1000 lines of code project if you want, but considering you’re learning something new, it’s highly unlikely you’ll finish it.

The cool thing about focusing on quantity, is that with time, by nature you’ll start to focus on quality. For example, imagine you first focus on doing a calculator, then you focus on doing a simple game, and finally you focus on getting weather data. At the beginning, it might feel pointless. But with time, you’ll notice you already acquired skills to get data from an API, run a program, and create a GUI for it. UNTIL THEN you get to let your imagination run wild. Not while you’re still learning the basics.

The framework

• Define what features the end result will have. (Also see Minimum Viable Product). Example:
  Weather Analysis
  — Today’s weather (pulled from an API)
  — A DataFrame holding the weather for every state
  — A bar chart showing the weather for every state
  — A map visualizing the weather for every state
  — An exported CSV of the data
• If an important new feature is discovered during the process, add it to your plan and work on it.
• After every feature is covered and working correctly, the project is marked as complete.

Where can I find projects though?

Ask Google. Ask Chat GPT. Anything but procrastinating. You can search for “Beginner [whatever you’re learning] projects” or try to emulate something you like. Just be realistic. If you barely know what CSS means, don’t try to build a Twitter clone. Get your hands dirty, pick up some speed, and then give the big projects a shot.

Search for projects on YouTube, Medium, books, or wherever you might find inspiration

Is cloning a project wrong?

Not at first. If you’re learning, cloning a project will save you time on thinking about design, framework, etc. It’s even encouraged, since you can practice and prove your skills on an expected result. At this point, the priority is getting to work.

It becomes wrong when you’re already fluent on a new skill. At that point you’ll end up harming your creativity and restrain your imagination. When solving problems, you’ll always end up thinking in terms of the projects you emulated, instead of free thinking (you know other stuff is possible, you’re brave enough to try, etc.).

But I’m comfy in my tutorial hell :(

Well you shouldn’t be. We should treat engineering like we treat art. Art is very fun and fulfilling, but only when we have the ability to bring our vision to life. When we don’t have the capacity or ability, we learn about colors, shapes, etc. But the fun part is creating, not emulating.

At first it’s going to be a little uncomfortable, because no one will be grabbing your hand. But after a few small projects you’ll gain some confidence and feel the need to create something of your own.

As a suggestion, for every tutorial you watch (if it’s a good one), do 1-3 mini-projects. If it sounds too hard, try doing 1 guided project, 1 semi-guided project (doing it on your own, but with reference) and 1 unguided project.

If we want to learn something new, we can’t escape tutorials. What we can do, is create a better relationship with them.