counter easy hit
How you should not wear a mask
How you should not wear a mask
July 15, 2020
What it was like learning programming in the early 1970s
What it was like learning programming in the early 1970s
July 17, 2020

The best way to learn how to code

The best way to learn how to code

The best way to learn how to code

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. One can’t help but wonder what’s the best way to learn how to code.

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 heads 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 learn 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.

Do 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? And what’s the best way to learn how to code?

Students enjoy computer science and arts the most!

Students enjoy computer science and arts the most!

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.

Here’s the best way to learn how to code:

  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.

You might also like: Tools to know before you start coding.

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). This is one of the best ways to learn how to code.

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.

Easiest programming languages to learn

Easiest programming languages to learn

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. Solving problems is probably the best way to learn how to code

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 six months of my life working on.

Beginners simply don’t have a source of intermediate tasks and resources to bridge the gap between knowing the 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

Want to know the best way to learn how to code? 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 that 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.

Difference between learning a programming language and learning to program

People tend to mix two distinct things (like you do as well):

  • learning a programming language

  • learning to program

The two items above are distinct and not the same in any matter. Especially beginners often confuse learning a programming language (in syntax and grammar) with learning to program (the actual, difficult part). This helps a lot on finding out the best way to learn how to code

Sure, in order to be able to program, one needs both, a language and knowing how to program.

The “best way to learn how to code” order of things:

  1. Learn syntax

  2. Solve problems

  3. Make stuff

is definitely not the worst approach, but it brings one major problem:

Learning out of context is more difficult than learning with a relatable context.

If you just initially focus on syntax, you learn without context – you memorize and memorizing and programming doesn’t go together. Memorizing kills programming creativity because after having memorized the general syntax (which up to a certain degree is a necessary evil), many beginners start memorizing algorithms in the context of their current programming language – and here is exactly where the problem lies. It doesn’t make sense to memorize an algorithm in a certain programming language – algorithms need to be understood on a conceptual, abstract level independent from programming languages.

You might also like: What programming language should I learn?
An example

In Java, you use a Scanner instance to obtain keyboard input, so people will write something along:

Scanner keyboard = new Scanner(;

// more code

int value = keyboard.nextInt();

A beginner might want to memorize the above snippet for later reuse.

Rather than memorizing the code, it is essential to understand what the code does and why it does what it does in a certain way.

So, instead of memorizing the code, it is better to memorize:

  • When I need input from a keyboard, I need some object that can acquire that input

  • When I need a certain value, I use one of the methods of the object above to obtain what I need

This abstract concept transfers well across many languages. Once understood, all that needs to be done is to translate the concept into the actual implementation in the required language. Be it Java, C#, C++, or any other language.

Another example:

I want to iterate through an array:

for(int i = 0; i <= myArray.length, i++) {
    // do something with myArray[i]

Again, the actual code is secondary. I only need to know that I need a way to access each and every element in the array. How exactly I do that depends on the language implementation.

This abstract or conceptual learning becomes even more important with data structures and algorithms. It is hardly ever necessary to be able to recite the implementation of any algorithm in any language, but it is very important to understand the algorithm on a conceptual level so that it can be implemented in any given language.

Solve problems is where most people drop out of programming.


Because solving problems requires to learn a different way of thinking – thinking in algorithms or abstract thinking. This is a purely acquired and trained skill that initially requires lots and lots of effort and is very hard. It definitely gets easier over time and with more practice.

Especially in this step, beginners often make one major mistake: They give up too quickly (“I’ve been on that problem for half an hour and can’t come up with a solution”) and resort to resources on the internet, which, in turn, frustrates them because often the solution is either very easy or way over their head.

When I learned to program, there was no internet and there were hardly any knowledgeable people around that could be asked, so I was forced to struggle and find the solutions on my own. Often, it took days to come up with something useful, but there was no other choice.

The internet with all its benefits has made people too much dependent and lots less self-sustaining. Instead of really biting through a problem it is way easier to fire up our good and essential friend, Dr. Google, and get the solution in a matter of seconds. Then, they implement the solution without spending time to actually understand it (copy-paste code monkey style) – which is a huge red flag. It is fine to look at other’s code, but only as a reference and help to understand it. Especially beginners should write every piece of code on their own. This trains problem solving and analyzing skills.

I am definitely stating that the more and longer you struggle with a problem, the better you will become as a programmer because you rely less on external sources.

Another issue

When attacking a new problem or task, beginners often directly rush to the keyboard and start programming away. Again, this is the wrong approach. Before even thinking about going near the computer, especially beginners should spend considerable time to analyze the problem and to devise a solution on paper (not necessarily in a real programming language). The time spent planning and thinking about the task is not wasted, rather the contrary is the case. The better a problem is analyzed, the more time is spent on consideration, the better the final result will be.

Again, back when I learned to program (before I bought my own computer), access to computers was extremely limited. I could access our school’s Apple ][ Europlus for two hours per week in a single session. So, the majority of my programming was done offline – without access to a computer. I planned, I wrote my code, I debugged the code in my mind, and then, when I was sure that it would work and produce the desired output, I used my session to actually type in the program. Most of the time, the programs worked without problems – besides occasional syntax errors produced during typing.

Learning to produce and trace code without a computer is an essential skill in the toolbelt of a programmer. This way, again, a programmer becomes self-sustaining.