The thing that really frustrated me when I first started learning to code was what I now call the “foggy bridge”. It’s a long and dark bridge where everything on the left is too easy and everything on the right is too hard. So you’re stuck aimlessly stumbling across this damn bridge not knowing what you don’t know.

Most people new to programming suffer from an inability to find intermediate tasks and sources of knowledge to bridge the gap between being a beginner and becoming a proficient coder. The people who make it across the bridge do it by endlessly grinding through simple tasks or hitting their head against the wall of a project that’s probably way beyond their current ability.

This results in the vast majority of beginners getting frustrated and giving up before they should. They burn out. Not because coding is hard (it’s not), but because learning to code is hard. And it really shouldn’t be.

So, is there a better way?

For over a year, I was literally obsessed with finding an answer to that question. What’s the best approach to learning how to code? It’s a deceptively simple question and the answer, as it turns out, perfectly explains why learning to code is so difficult in the first place. Or perhaps I should say why explaining to others how to learn is so misleading.

If you were to ask five developers what the best way to learn programming is, you’d probably get five very different answers. One guy will confidently say you have to start building real applications. Another guy will give you a huge list of links to blog posts, YouTube videos and online courses. There will be the guy who says his brother went to such-and-such bootcamp and it’s apparently awesome. The really nerdy looking guy will give you a .edu link to an introductory computer science course and somebody else will undoubtedly mention a well respected book or two.

You know what’s really frustrating about those responses? They’re all legitimately great answers. So why are you still left with that same feeling of discouragement you had when you first asked the question?

Here’s why: Learning to code is easiest when done in a particular order. When you try to learn it out of sequence, you’ll get really frustrated or really bored. Like trying to ride a bike without first using training wheels or learning your ABCs when you can already read and write.

The best way to cross the foggy bridge is to break it up into three separate but distinct segments. Think of these segments like you would think of borders on a map. They’re helpful for navigating but they aren’t real.

1. Learn syntax
2. Solve problems
3. Make stuff

Each segment is a prerequisite for what comes after, yet none of the segments are mutually exclusive. In other words, crossing the foggy bridge won’t be a strictly linear process. While each segment reinforces the others (independent of order) you should focus primarily on one segment at a time. If you do it that way, you’ll make it across the bridge faster, easier and with much less of a headache.

Let’s take a look at each segment in greater detail.

Learn syntax

This segment gives you a false sense of confidence which will quickly disappear when you move to problem solving. It’s the realm of countless introductory books, videos and courses. A lot of money is made in this segment because most people learn a bit of syntax and never go any further with it (not their fault, but I’ll get to that in just a sec).

There really isn’t anything lacking in this area. The market for learning the basics is so massive and so few people go beyond it, you’ll find an almost endless supply of material. Don’t get caught in the common trap of continuously learning and relearning syntax. Once you’ve read two decent beginner books on your language of choice, call it good and move on to solving problems.

Solve problems

Now this is an area desperately in need of some attention. It’s almost completely overlooked and I believe that’s the main reason so few people get past learning syntax. They have no direction other than vague advice to start making things, which is kind of like trying to ride a bike without ever having used training wheels. It’s possible but far from an ideal way to learn.

When you can take the syntax from the first segment and apply it without being told what to do, you’re in the problem solving segment. This is the very essence of thinking like a programmer and it is by far the most difficult and important part on your journey across the foggy bridge. In fact, It’s what I’ve spent the past 15 months (as of this post) working on.

Beginners simply don’t have a source of intermediate tasks and resources to bridge the gap between knowing basic syntax and actually building stuff with it. They’re left with no other choice but to stumble across the foggy bridge until eventually they start figuring things out through sheer brute force alone.

Make stuff

Pretty much every developer I know went straight from learning syntax to making stuff (or… trying to). It’s very frustrating because not only are you learning to think like a programmer, you’re also learning about frameworks, all the jargon that goes along with frameworks, how to use an IDE and a bunch of other things I won’t get into.

Once you understand syntax and can actually solve basic coding problems on your own, it’s time to either contribute to open source projects or work on some hair brained idea you’ve got. Build stuff that makes you excited to get out of bed in the morning and prevents you from falling asleep at night. Passion will get you past the remaining hard parts.

The reason so many people get frustrated and ultimately give up on learning to code isn’t because coding is hard. It’s because learning to code is hard. It’s messy, loaded with jargon and it leads to extreme information overload. There’s just so much stuff you need to learn. So at the very least, keep your approach simple.

1. Learn syntax
2. Solve problems
3. Make stuff

Generally in that order.