DEV Community

Cover image for Common behavioral mistakes of novice programmers and how to avoid them
Alex Yelenevych
Alex Yelenevych

Posted on

Common behavioral mistakes of novice programmers and how to avoid them

The mistakes of novice programmers, those who are just learning or just starting to work, are very similar to each other. Many of them can be called not mistakes, but behavioral features, stages all beginners go through. We as Java course creators are interested in this topic, so we interviewed opinion leaders and collected the most common, in their view, examples of such behavioral errors in order to … shorten their duration for future software developers. If you start noticing such behavioral mistakes early and try to fix them, your path to mastery will be shorter and your work will be more efficient.

Using wrong tools

The most common mistake everyone can observe among people starting programming is using the wrong tools, or not using the tools correctly. Sometimes they choose tools but ignore the task they need to solve with it. They heard something in advertising, or read reviews. Complete beginners are sometimes afraid to expand their toolbox. They can stubbornly ignore Git, the basics of which can be learned very quickly, use the first code editor they come across, an outdated IDE, the wrong framework, and so on.

“One example I’ve seen a few times is when beginners are not aware of VCS tools like Git, but instead use something like DropBox to store their code.”, Erik Hellman, Freelance Software Developer, said, “I have also seen beginners use MS Word for writing code, which can be quite funny to watch.”

Ignoring debugging

This mistake, of course, is a part of the previous point. A debugger is a tool too after all. Nevertheless, given the importance of this point and the fact that the debugging process is an important and valuable skill for any programmer, we took it out separately.

So … You work with statically typed languages like Java, C++, etc. Hence, there isn’t much to say here other than debugging your code! Try it right after writing your first programs. This is an extremely healthy habit and a must in your work. Moreover, at the time of starting your very first work, it is desirable that this skill is already confident. All modern IDEs (and, having solved the mistake of the previous paragraph, you will use modern IDE, right?) have excellent built-in debuggers with all the necessary functions. You can debug an entire program, its module, a single function, and so on. Read docs, watch youtube tutorials or ask your experienced friend to help. In any case, explore the debugger.

Copying without checking

Googling and copy-pasting someone else’s code isn’t really a crime. Quite the opposite: this process significantly speeds up the work and helps the developer in his constant learning. However, here is an important point: copy-paste should be thoughtful. Learn from it, try to get how this code works, modify it according to your task.

“Once beginners get past the challenge with all the tools, it tends to be a problem of not knowing how to find information. Copying code from the first StackOverflow answer they found or using outdated libraries is very common among new developers”, the software developer Eric Helman said.

Ignoring unit testing

Very often, newbies are not actually writing tests for their code and don’t test their code. Some novice developers check their code, but they do it in a very specific way. For example, they manually change the data in the program and output the result to the console. In fact, you need to start unlearning this method right after you have mastered the basic syntax.

“Thoroughly oftentimes people do manual tests but not of the cases. Getting comfortable with unit testing, getting comfortable with understanding all the edge cases of your code, and working through them. That’s one of the more likely snares of people are going to mess up on and then if you’re really getting your career started consistently”, Dylan Israel, software developer, and YouTube Content creator commented.

Falling in the tutorials hell trap

Newbies often get lost and don’t know exactly where to learn new information and how to learn it. Instead, they watch video after video, looking for more and more new stories. Here’s what Vadim Savin, Software engineer, and Youtube content creator, says.

“The most common mistake I see newbie programmers do is falling in the tutorials hell trap. How many udemy courses have you bought, and how many of them have you finished? The problem is not with tutorials, because you can learn a lot from them, the problem is the lack of practical experience. If you want to be the best at basketball, you wouldn’t watch tutorials all day and read books for a year, you would get on the court and start practicing. That’s the same with learning programming. Start building projects. When following a tutorial, don’t just watch, but do the same thing as the tutor is doing. Then, try again, but this time from memory. After you get the basics, start implementing the new knowledge in real projects. Start building that website/app/game that you have always wanted to build. This way, you will be motivated to practice because you will work on something you are excited about, and you want to feel the burden of learning”.

Fear and overreaction on code review

One of the obvious mistakes novice programmers make is a sharp reaction to code review. Very often, newcomers perceive the remarks of colleagues as harsh criticism, get upset, offer resistance, trying to prove that they were wrong. In fact, code review is a procedure for improving code, and not only for a newbie. For a beginner programmer, this is a great opportunity to learn on the job. Think of the process this way. Nobody wants to offend or humiliate you (well, most likely nobody, some people are strange when you are a stranger). Everyone is trying to ensure that your overall project is of the highest quality possible. Of course, the reviewer is not a saint and can also be wrong. It is important that you argue these points without emotion, try to look at your code with detachment and calmness.

Too much or not enough efforts

This problem is like a double-edged sword. On the one hand, many developers put in too little effort and abandon a difficult task that they can do, because they are not sure they can solve it. On the other hand, there are those who, on the contrary, can torment themselves for a very long time over a task that should have long been abandoned. As a result, the former does not develop fast enough, and the latter loses motivation. Here’s what our experts have to say about it.

Karolina Sowinska, a data pro and a YouTube content creator:

“I think the largest mistake that new programmers make is not trusting yourself enough to stick with a problem to solve it. That’s certainly the mistake I was making at the beginning. I thought that I don’t have enough knowledge or experience to be able to solve a difficult issue. In reality, facing unknown problems is exactly what experienced software engineers do on an everyday basis. You will not feel comfortable 70% of the time. So it’s paramount to shift your mindset from “I can’t solve it yet” to “I will solve it no matter what” regardless of how much experience in coding you have”.

Masha Zvereva, founder at Coding Blonde YouTube channel:

“One of the biggest issues I see newbie programmers struggle with is a combination of impatience, comparing themselves to others, and self-doubt. Learning how to program is hard and requires a different type of logic than what we’re used to in our day-to-day life, so it takes time to properly understand certain concepts. And different people will learn different aspects of programming quicker than others, but that doesn’t mean anything about their intelligence or future opportunities. Everyone is on their own timeline and has their unique learning style. Be patient with yourself and use additional materials if the ones in front of you don’t make sense to you”.

Saldina Nurak software engineer and YouTube channel autor:

“The main mistake that new programmers make is either self-doubt and thinking that they are not smart enough, or the complete opposite of that, thinking that they know everything, when in fact they don’t.
Looking back to my university days I can say that I was in the first category. I could understand the code during the lectures when professors explained it, but I had problems solving those same tasks alone, so I was wondering if I just wasn’t smart enough.
Now I know that it is because I didn’t spend enough time practicing. It’s the same when you are learning a new language, most people are able to understand it before they can speak it.
Some of the tips that helped me to overcome that issue and become better at programming are naming variables and functions according to their purpose, using diagrams and pseudo code when I couldn’t understand the code itself, writing comments for later reference, being consistent, and trying to learn a little bit every day, building a solid foundation and filling all the little gaps that I had in my knowledge.”


Ask a newbie programmer, what in their opinion the ideal code should be. The common answer would be “optimal, of course!” This usually means “optimal” in terms of performance and resource consumption. It’s a logical answer, isn’t it? Yep, this is so in an ideal world, but, alas, we don’t live in one.

Therefore, this answer is fundamentally wrong, especially when it comes to large projects that will be used and supported for many years. Experienced developers will choose the latter between optimality and readability. They know that, while optimally, Junior’s over-engineered code is so difficult to read and maintain that it will likely need to be rewritten completely soon. And if you see in front of you an even formatted code without frills, you can say it is boring, most likely it was created by an experienced programmer.

By the way, such code will most likely contain comments. And they will be exactly where they are needed. Moving on to the next error.

Where are your comments, dude?

Comments … Newbies and comments are just an ancient tragedy. Comments could be literally everywhere and explain the obvious things, or vice versa, code without comments at all. Don’t be like this, please. Explain what isn’t readable in an easy way or is referencing other modules.

“One of the common mistakes is the “We don’t need no stinkin’ comments” with apologies to The Treasure of the Sierra Madre where the original version of this line came from. Just last week while discussing this issue it was suggested that comments are worthless because when code is updated or refactored the comments are rarely updated so we might as well do away with them.” — Ken Fogel, Java Champion, CS teacher at Dawson College shares, “I once had to remove comments from submission to an open-source project. Comments represent the technical manual complex systems required. Imagine having to repair a modern automobile without the shop manual.”

Sure, competent commenting is a special science. However, if you master it, your colleagues will be very grateful to you. Remember the times when you had to understand someone else’s code. I think someone’s literate comments helped you, right? If you find it difficult to understand how to correctly place comments, look at the libraries of your programming language that you use, read, comments on their code … Learn from the best.

Messy code formatting and frustrating names

Sometimes novice developers don’t understand the importance of standardizing their coding. They have not yet realized how difficult it is to navigate someone else’s code, and don’t understand that they write code not only and not so much for themselves.

Each language has a set of rules that describe the correct formatting of the code. Some IDEs already know how to format the code in a standard way on a wave of hotkeys. Take the time to find out how to do it in your case. However, there are many things you still need to keep track of yourself.

Even more dramatic is the naming of variables and functions. If in the learning task int p; looked quite adequate, in a module of a large project it’s not! persentOfYearIncome looks terrible, but it is much clearer what we are talking about. By the way, don’t try to use short names and write transcripts in the comments. Better not be lazy and pick up your variables. functions, classes have friendly names. Even if they are not the most elegant.


“I would actually consider mistakes to be very healthy. It’s what teaches you the most as you try to solve a problem that you did not plan for. I think if I was to name an action that a programmer might do and call it a “mistake” it would be when we come across an issue in the code and we simply give up,” software developer and YouTube author Filip Grebowski said.

And I definitely agree with him. Mistakes are something that we cannot avoid as programmers. Everyone makes them, even the most proficient experts. Try not to repeat the same mistakes all the time and you become a better programmer faster.

First published at Geek Culture.

Top comments (1)

jonrandy profile image
Jon Randy 🎖️

I'm a senior developer/tech lead and have never practiced unit testing in over 25 years. It's possible to go without it