Programming Tutorials aren’t Always the Answer

Stop me if you’ve heard this one before. I’d start a project with a tutorial, learn a thing or two, and then just hit a wall. In order to proceed, it seemed like the only thing to do was to copy code from the tutorial without entirely understanding what it did. When I inevitably tried to do something slightly different (because I want to make my own project, not necessarily the project the tutorial was making), I’d break things, and never figure out how to get my project working again. I’d stop working on it.

I repeated this pattern over and over again for years. To be clear, this isn’t because the tutorials I was following were bad. Quite the opposite! They were fantastic guides, filled with informative commentary, code, and just covered with polish and effort. The problem wasn’t with the tutorials. It was with me, and how I learn.

While I find many tutorial resources aren’t for me personally, there’s still tons of content out there I’d recommend. Check out Khan Academy courses and Catlike Coding!

Why Tutorials don’t Work for Me

The short answer is “A lot of things”.

The biggest problem for me while trying to learn from tutorials is that I can’t really control the curriculum. The lesson could be stuff I’m really comfortable with, but then suddenly veer into deep water very fast, leaving me floundering. It’s not that the tutorial is bad (or that I’m bad either, for that matter), but just that it didn’t mesh with my skill set. A tutorial by its very nature can’t always meet my specific needs. I have comfortable areas and areas I’m far less comfortable with. As we’ll see later, my best learning really strongly focuses a balance between comfort and extension, and most tutorials just aren’t designed to walk my personal tightrope of preferences.

Oh, by the way, all of this doesn’t mean I’m special, or that I just learn in some unique way. Mostly it means that I’m stubborn, and prone to certain mistakes.

Speaking of mistakes, the next mistake I make is the tutorial modification trap. If I’m making a game, I want my game to be personal, and that means almost by definition that I don’t want to do exactly what the tutorial has done. I want to do something similar, but never an exact copy. I don’t want a generic RTS game, I want my RTS game.

Even the best tutorials can’t help but guide people down a path they’ve already tread. When I stray off the path, because I want to do something I think is interesting, it invalidates the rest of the tutorial. I can’t follow the next lesson because it builds on a foundation that I’ve modified instead. This wouldn’t be a problem if I knew what I was doing for the next step, but I’ve foolished cut myself off from the very part of the tutorial that was going to teach me! It’s curiosity killing the cat all over again.

Just for Reference

There’s one last thing that I personally dislike about many tutorials. They tend to make less than ideal reference material at the end. Over the course of a lesson, a good tutorial might cover a dozen little tidbits of good code architecture, algorithms, and techniques, all in the service of the lesson goal. Very frequently, I find myself more interested in those tidbits than I am in the end product. If my end goal is to take the knowledge of a good tutorial and apply it to my own programming, then I care about the building blocks more than I care about recreating the end result. This means a lot of scrubbing through videos, looking for an offhand line about why the author programmed something a certain way.

One other petty thing is that I really dislike videos as a tutorial format. They’re great to digest once, but awful to step through, constantly pausing and unpausing, staring at text that can’t be highlighted, copied, or zoomed. Give me a written tutorial any day.

CGMatter does a hilarious parody of this, while also informing you about the content. If you’re looking for a laugh and some sweet blender skillz, check him out.

Correcting some Bad Habits

So if tutorials don’t work for me, what does? You don’t just learn code syntax magically, so how do I manage to learn new things? I’ll get to that in a second, but first let’s talk about the specific issues I sought to fix with my work habits, highlighted by tutorials, but not caused by them.

There were two big things I wanted to fix. The first was where I couldn’t get something to work without copying code. I simply set a rule to write all code entirely by myself. Copying code is a bad habit, and sometimes self-imposed rules can help curtail them. If I couldn’t write it, well, I’d figure something else, but copying code to fix my programming project is a poisoned apple. Putting code you can’t modify and can’t maintain into your codebase is a death sentence. It will slowly prevent you adding to and improving your project.

So if I can’t copy code to do what I want, how can I expand my project? Before, I’d seek out a tutorial that goes whole hog, and covers every element of a game genre that I could possibly want. Now, right at the start in the planning phase, I always design with my skill limitations in mind. If I know I can’t do path-finding, I will try very hard to design a game that didn’t need it (As a fun aside, at the time of writing this, I had just done my first ever A* pathfinding implementation a day ago, after 5 years of game programming). You can think of it as programming by necessity, not by requirements. By programming only what I know I can create, I create a sort of “cushion” of effort that I can guarantee is achievable.

Both of these things ensure my code is always comfortable. I might try something bigger and more complicated than I had done before, but it’ll always be made of parts I understand.

So if I’m playing it so safe all the time, how do I ever learn?

Slow Growth

Very naturally, almost imperceptibly really, I’ll expand the scope of a project as I work on it. As I expand, I’ll naturally run up against the fringes of my knowledge. I find I tend to learn the best, not when I’m plopped down into unfamiliar territory, but when I’m doing something that’s just outside my comfort zone. So with that in mind, my goal shifted from trying to program some specific thing, and more towards trying to keep programming on a project for as long as possible, keeping my fringes expanding, and finding new things to learn, bit by bit.

That’s where the “programming by necessity” thing above comes in. By keeping my core project as simple and as familiar to me as possible, I keep it easy to work on and easy to expand on. As I gradually expand, I’ll slowly learn one thing or another as I come across them. A new design pattern here, or a new data type there, and next thing you know, I’ve mastered a new part of programming.

So long as I can keep the core of my project accessible and leave myself avenues to develop down, I can always back down from something that’s too challenging. There’s absolutely no shame for biting off more than you can chew! You should just make sure to have a contingency so you’re not discouraged by it. Discouragement kills projects, not inexperience and when your project dies, so does your opportunity for learning.

Tutorials encourage growth and new projects, yes, but I think my personal pace is a little slower, and ultimately a little less deliberate. I find when I hit the end of a tutorial, I’m left thinking “what now?”, and I frequently abandon soon after, even if I was engaged in the material. The sorts of projects I create from tutorials can be helpful, absolutely, but just aren’t the best way I personally learn.

Hey, learning is hard even at the best of times. At the time of writing, I’ve been working on my current project for just over four months, but that’s way longer than anything else I’ve tried, and I’m really happy knowing I’ve learnt so much from it already. Tutorial or not, successful or not, I think it’s most helpful to take the view that every project is a step forward.

In short, don’t worry if tutorials aren’t for you, focus on keeping yourself programming, and let yourself slowly and naturally learn as you get more proficient and comfortable. Keep on at it!



Like this: Like Loading...