The Best Way to Learn How to Coding

mattmac profile image Matt MacPherson Updated on ・5 min read

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.

Posted on by:

mattmac profile

Matt MacPherson


Software developer, entrepreneur and master of the intertubes.


Learn to code with 10,000+ interactive challenges. Gain XP, unlock achievements and level up. It's like Duolingo for learning to code.


markdown guide

What a great article!

I feel you on ,

You know what’s really frustrating about those responses? They’re all legitimately great answers.

We need to be patient with ourselves and find our own way.

We have the same goal: to learn how to code.
We have different pathways to get there. It's all about patience, knowing yourself, and knowing what works for you.

Thanks for writing this! It prompted some great introspection.


Thank you! I really enjoyed reading your post on Frankenstein code the other day; it's pretty much exactly how I learned. I started that journey about 18 years ago with mIRC scripting. Mmm, nostalgia. 😎


I'm addicted to edabit. It is so much fun. I 100% agree that it is the best way to learn. I've been programming for over 20 years. I learn something everyday on edabit.

Some users like to play code golf with it while others post more readable solutions. Either way, you learn and have fun.

If you're looking to level-up, do enough of these and you will find that you need the internet less and less. Then, the next time you're asked to live code in an interview, you'll crank it out.

Thank you Matt!


Matt, thanks for the article and the creation of edabit. In about 2 days with edabit I feel like I have a much better practical understanding of how to manipulate python lists and I've even learned some new approaches (syntactically and otherwise) thanks to the resources and solutions tabs on each problem. This is a great tool and I feel like I'm perfectly in the middle stage of programming you describe in this article (i.e. "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.")

I've occasionally jumped into making stuff (because I had a problem to solve), but even with those wins I felt like my general understanding of programming was limited to the problems I solved (and therefore limited to the problems I could come up with and devote time to). This didn't help my overall feeling that I could really leverage code effectively/quickly enough to invest the time.

In short: thanks for edabit. It's proving (to me) that I basically understand the syntax and how to do things, but it's also increasing my self-efficacy for generally being able to approach problems more quickly with code―which changes my calculation for whether or not it's worth investing the time in coding up a solution.

Thanks for making making more accessible.


Thank you for the encouragement! This kind of feedback really makes doing what I'm doing worth it. Also, I fixed that annoying Python indentation error yesterday (I'm sure you ran into it a few times). If you've got any ideas for site improvements please let me know!! :D


I did run into that error many times! Glad to know it's fixed! I'll certainly send some improvement ideas along as I progress through. I'll try to keep a running list of minor annoyances. The core concept is great though, and really helpful to someone like me. Very much appreciated!


This is a great article. i like it.
Can you give 2 or more example list in the Solve Problem segment.

thanks for the article.


This definitely describes my experience with learning a new programming language.

I really appreciate you creating the Edabit website. It has definitely helped me by putting my Python experience to use to solidify what I have learned.

  • Any possibility of adding Golang to the list of Edabit languages?
  • I have a hard time finding things for this part. I'd really like to find some to put the skills to use:

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.


Good article. Great work. Equally useful to the newbies and oldies. This infographic will help in understanding the Artificial Intelligence Trends & Applications To Watch In 2020


Thank you Matt for this wonderful post. I myself being a self-taught developer struggle with this daily. I feel by implementing some of your strategies it will help me to become a more confident developer.


Thanks, Matt! I'm in about step 2 of my journey into programming :D


I don't even know where to begin. This post is exactly what I have felt for a while now. You are so correct when you said a big industry is built on beginner books about syntax but then when you jump to things like design patterns and data structures and algorithms it leaves the people who are self taught or just beginning with this paralyzing fear or view that they are never going to learn this stuff.

Many thanks for this great article. If you have time could you expand on problem 2. solving problems. I think the step from 1 -> 2 is by far the biggest but once you get to 2, I think jump to 3 becomes easier.


Wow this is a great article and it sounds like what I'm going through right now. I'm 46 and I've been learning to code about a year. Right now I'm an intermediate coder, and I'm in a situation where I can't find any intermediate stuff online. Luckily, someone from Reddit told me about edabit.com. All I can say is it is a great place to practice. I solved a couple of Mr. MacPherson's script. Thank you very much.


This blog post and edabit.com looks like an answer to my prayers! Thank you!


I liked the approach, but for someone who is beginning, it would be important to choose a language wich its syntax and problem solving patterns are inherited by major of languages.


Most popular languages are based on C syntax. Exceptions being Python and Ruby. Problem solving patterns are pretty much universal so far as I can tell... Functions, loops, variables, conditionals, etc. I don’t believe the syntax part is very important. Most people can pick it up relatively quickly. Solving problems with syntax is the challenging part.