5 Beginner Mistakes You Should Avoid When You Try to Learn Programming

Learning programming is not easy – I think we can all agree on that. But with enough effort and perseverance – and a lot of patience – we can slowly but steadily get good at it. It’s just a matter of time.

However, you have to make sure that your approach to learning is right, otherwise you will slow down your progress unnecessarily. In this post, we will take a look at the most common mistakes beginners do when they try to learn programming.

 

Learning too passively

The biggest mistake, in my opinion, is trying to learn programming by watching tutorials or reading books without actually writing a lot of code yourself. We are not machines that can just “download” knowledge by parsing it from letters and then storing it in our memory 1:1. We have to slowly build and strengthen connections in our brain by actively practicing things over and over again. Even if a tutorial totally makes sense to you at the time you read or watch it, you won’t remember a damn thing when you later try to reproduce it for the first time. Chances are, you’ve already made this experience and realized how bad of a learning strategy that is. Ideally, you should practice every new concept and every part of a tutorial that you want to learn immediately, even if it seems unnecessary at this moment. Otherwise it will simply not stick.

But here’s another important thing: It’s not enough to just type out the code from a tutorial and follow every instruction one by one. This is still a very lazy approach. If you watch a lesson and do the exact same steps, it’s certainly better than not writing any code at all, but in order to really learn something, you have to think for yourself. And you do this by building your very own project rather than copying an existing one.

Let me give you an example from my own mistake: Recently I tried to learn a new concept from one of the Google Codelab exercises. So I set up the same project as in the tutorial, followed everything step by step, named my variables the same and created the same Java classes and layouts. At the end of this course, my app was working, but I had no idea how. I didn’t learn a thing. If I tried to write the app again without help, I would have not been able to do it. The problem was, that I approached this tutorial too lazily and didn’t make myself think enough in the process. So I deleted the whole project and started from scratch, but this time I came up with my own app idea and slightly different features, classes, variables and layouts. On every step in the course, I read the instructions, looked at the example, then minimized the tutorial and tried to build it into my own project. Whenever I didn’t know how to do something (and that was often), I first looked at the Codelab, and if I couldn’t find the solution there or if it wasn’t explained properly (which also was very often), I did a Google search. This second time, finishing the tutorial took much longer, but at the end I understood what I built there and I really internalized the concepts. Later I made sure to repeat what I learned so I don’t forget it.

Remember this: Getting spoon-fed the solution is never a good way to learn something, and you should pay attention to when you are doing that. Being proactive in your learning process also means not relying too much on others to solve your problems. In communities and under Youtube videos I often see people asking very broad questions, like “how can I implement feature X” or “I get this error message, what should I do?”. Unless it’s a very rare and special functionality or error, these are the wrong questions to ask other developers. These questions should be searched in Google. You should only ask other people if you run into a very specific problem for which you didn’t find a solution after extensive research. It’s not so much about saving other’s time, it’s about you, because you benefit the most from searching for yourself. You understand things much better by seeing different examples, reading other people’s code, trying things out and drawing your own conclusions, rather than just getting a well-prepared answer served by someone who is already an expert in that area. It’s the process of solving a problem that matters, not so much the solution itself.

Don’t get me wrong. I think you should ask a lot of question, but those questions should be very specific and about problems you encountered after lots of research. Your questions should come from a curiosity to dig deeper, not from laziness.

 

Trying to memorize the code

Some people think that being a good programmer is about memorizing all the different algorithms and knowing a lot of different APIs, and under my videos people sometimes ask how I can remember all this stuff. The answer is: I don’t. Or at least I don’t actively try to. If I want to know which class (or method, or any other form of code) I have to use for a task, or if I forgot how the syntax for a certain operation looked, I google it. If I use it repeatedly, I will eventually memorize it. If I don’t use it regularly, it doesn’t seem to be that important to remember. Any modern IDE autocompletes a lot of code for you and shows you warnings if your syntax is wrong.

What you instead have to focus on, is understanding the underlying concepts, data structures and design patterns. The keyword here is understanding. Try to figure out what each part in your program does, what the APIs that you’re using do, and how it all works together. You do this by learning very proactively as we discussed in the previous paragraph.

At this point a little tip: On my tutorials page, you can find the code snippets for most of my Youtube videos. If you ever try to remember how something from one of my videos worked, you can take a quick look there and get a refresher.

 

Not focusing on one area

When you first start to learn programming, decide for a language and framework and then stick to it for a while. How long? I don’t know, but I can tell you that I started learning Android and Java more than 1 year ago, and I feel like if I would switch now, it would be too early. Instead of diving deeper into the topic and understanding more advanced concepts, I would go back to learning the basics of a new language and framework. I would be busy getting used to the different syntax and APIs I have to use for the simplest things.  Sure, you could alternate between different languages, but then you would learn each of them much more slowly than if you give one of them your full attention. When you learn something new and then not look at it for a couple days, it’s very unlikely that you will remember it. Also, the danger that you switch back and forth as soon as something gets difficult, is too big.

Sticking to one topic requires discipline, because things get more difficult and more frustrating and your brain demands novelty and ease. But in my opinion, you should fight this urge if you want to become good quickly. If you simply code for fun, then this probably doesn’t matter too much. But if you plan to become really good, for example to get a great job in an area you’re interested in, you should probably specialize, rather than learning a lot of different things just a little bit. Unless, of course, the position you are aiming for requires these different topics.

As I already explained earlier, learning programming is about adopting a certain way of thinking and learning how to solve problems. A lot of experienced developers say, that once you are sufficient in one language, switching to another one becomes pretty easy because the overall concepts are the same and only the syntax and details are different. But for this, you have to become sufficient in a language first and not confuse yourself with the varying syntax all the time.

 

Learning too infrequently

Since you need repetition to learn programming, you should try to write a little bit of code on every day that you have time for it, especially if you are a beginner. Of course this depends on your schedule and responsibilities and there might be days where it’s just not possible, but often there is room for at least half an hour or twenty minutes somewhere in your schedule. I don’t ask you to go hardcore every day, I just want you to not leave too big gaps between single programming sessions.

Even if you are super motivated in the beginning, there will be times where you just don’t want to code. Relying on your mood is a bad strategy, so you need systems that help you keep going even if you don’t feel like it. Scheduling your practice time is a great way to make sure that you actually stick to your plans. If you have trouble with procrastination, check this blog post.

 

Being afraid of mistakes

Learning programming will make you feel dumb at times, because it’s very difficult. The natural reaction to this negative emotion is avoidance: Not opening the IDE for a couple days or doing easy stuff instead, like writing the same features and using the same APIs that you already know in and out. Or you spend hours in forums answering questions from beginners because it makes you feel competent.

But as I already said before, in order to get better at programming, you have to learn new, difficult concepts and then you have to repeat these concepts early and often so you remember them. On the other hand, you can’t learn effectively without mistakes and frustration, because they are a sign that you entered an area that you don’t already know. And ultimately, this is what we want. If learning programming feels easy all the time and you get everything right at your first try, what did you learn in the process? Probably not much.

In the previous paragraph, I hinted that proper planning can help you keep going even when your motivation is low. That usually works pretty well, but if you don’t watch out, coding can quickly turn into a chore and lose all its joy. In something as learning-heavy as programming, you have to change the way you see challenges, otherwise you will grow to hate it and always seek for an easy way out. The journey is really the whole experience. You can’t hope for day X where you suddenly don’t have to learn anything new anymore and you can just lean back and let the code flow out of your fingertips. But just the imagination bores me to death.

The difference between enjoying the learning process, and dreading it, is mainly a mindset thing. You have to detach yourself from the results and reframe every new problem that comes up as it’s own little learning opportunity. Approach every question with curiosity. Be patient and try to enjoy every search for an answer. It doesn’t matter if you solve the problem right now or if it takes weeks, what matters is that you are learning and progressing. Mistakes and frustration are positive, because they indicate growth. Just like the pain you get from the last few repetitions when you lift a weight in the gym.

When you detach yourself from the result and keep your focus on the process, you are also less afraid to get rid of outdated knowledge and wrong approaches. You don’t see this as wasted time, because it made you a better overall programmer and you had fun along the way. Being process-oriented doesn’t mean you don’t care about the outcome. Actually quite the opposite, you always do your best on a moment-to-moment basis, and then you know that you will naturally get to the best results.

If you stay on track and just keep practicing, you will be amazed by how quickly you will get better.

 

Ok, these tips should help you in your journey to becoming a good programmer. They certainly help me in mine. Let’s learn together and enjoy the process as much as we can.