Learning a new skill is hard. Part of what’s so hard about it is, by definition, you don’t know the skill and so you also don’t know the best way to go about learning it. So you rely on people who do know that skill to guide you through the process. Maybe you’re a child, relying on your parents to teach you how to ride a bicycle. Or maybe you’re an adult who just Googled “how to learn to code.”

Unfortunately, most people who know things are not good at teaching them. Learning a skill and teaching that skill are two separate abilities. Often we learn things and then forget just how we came to understand them.

Emily Oster recently discussed balance bikes vs training wheels for learning to cycle. A balance bike is a bike without pedals that a child can push around with their feet. The research on learning to cycle in these two different ways is light, but Oster quotes a Portuguese study that says kids who use balance bikes learn to ride around age 4 while kids who use training wheels don’t manage until age 6. (The study didn’t establish causality, but I think it’s probably causal.)

Training wheels and balance bikes are both part of the same essential learning strategy: start with a simplified version of the thing you want to learn so you can learn specific parts of it and ignore the other parts. The difference is that training wheels remove the balancing part of cycling to focus on pedaling, while balance bikes remove the pedaling part of cycling to focus on balancing. I think balance bikes are better because staying balanced on a moving bicycle is more important than being able to pedal. Knowing how to pedal is no good if you fall off the bike. If you can coast on a bicycle without falling off, you have plenty of time to learn to pedal.

Last year I tried learning to code in Solidity, the programming language used to write Ethereum smart contracts. I already know how to program in R and Python, so I figured it wouldn’t be too hard to learn another programming language. I found a series of tutorials and slavishly followed them. In the end, I learned…nothing. I couldn’t program in Solidity.

Tutorials, like training wheels, remove some parts of programming to focus on other parts. What they focus on is learning the syntax of the language and going through the steps of making some specific project. What they remove is basically everything else.

Programming is about problem-solving. It’s about knowing what you want to do, planning out the steps to do it, and then executing those steps. In order to plan your approach, you need to know what the programming language is capable of. You don’t necessarily need every command memorized, so long as you know they exist and where you can look them up.

Programming tutorials take away the planning part of programming. You learn the specific syntax of the exact code you’re typing, but you don’t learn the important things that went into the decision to type that code. You’re the guy who memorized some phrases in a foreign language, but you know nothing of its grammar.

OK, but surely there are better tutorials? What if the guy running the tutorial explained his whole thought process in exacting detail? That wouldn’t work because it’s too much information for your brain to take in at once. We need simplicity to learn, but we need the right kind of simplicity.

The best video I’ve seen on how to learn programming came from a YouTube channel about video games.

The guy in the video, Mark, talks about his experience trying to learn Unity with tutorials. He had much the same experience I had with Solidity: he followed every step in the tutorial and learned nothing in the process. It all went in one ear and out the other.

Rather than giving up, he took a different approach. First, he made a list of the basic building blocks of making video games. Simple stuff like “make a character appear on-screen” and “make the character move” and “make the character respond to user input.” Then once he had the list of absolute basics, he went about finding out how to do each of those basic steps.

Now equipped with the absolute most basic Unity skills, he set about re-creating the game Flappy Bird, a very simple mobile game where you click on a bird to make it flap its wings to fly through a series of gaps without crashing.

Note what he did NOT do. He didn’t follow a “how to make Flappy Bird” tutorial. He used tutorials for the absolute basic building blocks like making an image appear, and then he used those building blocks to make a clone of Flappy Bird. The act of combining individual commands into more complex processes is the essence of programming, and by learning the building blocks first and then combining them himself, he started to really learn how to develop with Unity. And once he knew enough to start messing around and making things, the deeper learning came on its own.

Our brains have limits to how much they can learn all at once. Learning a complex skill requires us to break it down into smaller, simpler chunks that our brains can handle. But it matters which chunks we learn first because some will make it easier to experiment and learn more, while others are learning dead ends.

When you are learning or teaching something, focus on basic building blocks that you need to start productively practicing the skill. Make a list of the building blocks you think you need and tick them off one by one as you learn them. Try completing a project using those building blocks, and use any place you get stuck as a cue that there’s some building block missing. Once you’re at the “messing around and doing things badly” stage, you’ve already passed the hardest part of the learning process. The rest is just practice, which you’ll naturally get if you’re doing something you’re motivated to do.