5 mistakes of every beginner programmer

When beginning to learn to program, you may feel overwhelmed by the huge amount of topics that you come across every day. It’s easy to get lost from the path. To overcome those problems, it’s important for you to avoid some mistakes right from the beginning.

Here are some tips that you may find useful and that will help you to get a smooth start of your programming career.

1- Not using version control system

Learning how to use some VCS should be your priority, as soon as you start being a bit comfortable with code.

It may feel exhaustive at first, learning about something else when you don’t really know how to write code properly. But as long as you’ll become more comfortable writing code, you’ll appreciate that skill.

There are tons of advanced features, that are important to learn about. But when beginning, I would focus on setting up repository and committing. This will allow you to track your progress. Then, it is also important to learn the concept of fetching / pulling and pushing, so you’ll be able to have an online repository as a form of a backup.

When you’ll become more advanced, you’ll find the possibilities of VCS and topics to learn next by yourself!

2- Not reading code from better programmers

I believe that this is an important part of learning. It may feel a bit weird, spending your time reading someone else’s code. But it can have a big positive impact on your progress.

With a huge open source community, you have the opportunity to learn from the great programmers. Find some popular project in a language you are learning and dig into it. You don’t have to (and you’ll not) understand everything, just try to analyze small parts of the code. Better you’ll get, more you’ll understand.

3- Switching languages / technologies quickly

It may feel good to know a little bit of everything. Jumping between languages and technologies is definitely interesting. But if you are doing it too often, it’ll be counter-productive and can cause you a lot of damages.

Instead, I would advise you to stick to the one language until you have a decent knowledge of how it works. If you’ll have strong knowledge about one technology, it’ll be easier for you to switch to something else, because you’ll be able to pick based on your present experience. You’ll know what you want and what you don’t. You’ll understand the differences better and you’ll be able to build on that knowledge after the switch.

4- Not finishing your home projects

That’s something, that I’ve been struggling with. I have strong interests in software architecture and I like to try different patterns/frameworks/approaches to learn the best practices for some specific needs. But usually, after I write a core part with a supported code to form a minimal working demo, I tend to ”throw it away” and jump to something else.

It is not a huge problem, but I think that you should complete your projects at least from time to time. It’ll teach you self-discipline, care for details and you’ll be forced to do the boring stuff too. And you’ll have something to present yourself when needed.

5- Not caring about the code quality vs caring too much

I believe that there should be a balance between the code quality and productivity. When starting, you struggle with making something work, so it’s obvious that you don’t really know and care about code quality and best practices. And it’s perfectly fine!

Ugly code that is solving the problem is better than beautiful broken code.

First, you should care about solving a problem, then focus on improvements, analyze your decisions and mistakes and try to learn from them. And learning how to refactor your code into better one is a valuable skill to have. So, not caring about the code quality is fine, as long as you are aware of that and you are willing to do a cleanup at the end (after you learned something new).

On the other side, caring about the code quality, design patterns and architecture too much isn’t good either. Code quality is important and you should have strongly defined conventions! But if you do not find your balance, you might over-architecture your application. Which means, you are not doing valuable (”actual” work).

BONUS- Not unit-testing your code

Unit testing may feel like somehow duplicating yourself for nothing. But including testing into your workflow will be beneficial in many ways.

By writing testable code, you are forcing yourself to think about dependencies (as hard-coupled dependencies are hard to test). Simply said, testable code is better code. You can also be sure that your code is doing exactly what it’s supposed to do and you can do refactoring without worrying too much.