10 mistakes I made when I started programming

This post was originally published on May 31, 2020 on my blog.

01. Self-doubt

This feeling is something that anyone can have and does not apply only on programming but in every aspect of life. Personally, I believe that the self-doubt is the number one mistake you can make as a beginner programmer. When you think that you’re not good enough or smart enough, then you will never achieve what you are aiming. I believe that anyone can learn to program to at least a basic level, if they stick with it.

Code might seem very daunting at the beginning and you’ll probably think that this is not for you. That’s normal! But day by day and with constant occupation you learn what each part does, and it’s not scary anymore, and then you see it starts making sense and how things are connected together. Undoubtedly, there are people that can grasp notions of algorithms very quick and write good code sooner than others, but, without hard work and hours spent on actual coding, reading tutorials/books will never reach their full potential.

02. Not linting my code

Do you want to know if the code was written by an experienced programmer? If yes, then you should be able to see a well-formatted code having consistency on indentation and its logical structure. By tabbing or spacing code in from the edge of the window, we show where functions, loops and conditionals start and end, so we can be sure all our code is in the right place. That makes the code readable and less prone to syntax errors that could lead to bugs in the long run.

Here comes the linter which is a powerful tool providing an easy way to scan your code and fix any syntax anomalies. You can easily use Prettier alone just to format your code, which works just fine. But, if you combine this with an ESLint process, you get both a powerful linter and a powerful fixer.

03. Poor variable and function names

I used to name the variables and function names just with whatever I came up with when I was writing code. Apparently, that was a huge mistake. One of the best factors that indicate that the code you’re working on is clean, the function turn out to be pretty much what you expected to be. Therefore, naming variables as descriptive as you can is one of the first and most important things you can do to create code that feels expected.

The intent of the code becomes a lot clearer, and you can easily understand what a function does by just reading its name. And apart from that, when you will have to deal with legacy code you will thank your past self for giving proper names to both variables and functions in the first place.

04. Belief of knowing it all

After some days or months of persistence and hard work on learning how to code and when you see some actual results then it happens! Your confidence grows, you feel powerful having the fundamental knowledge for building things and you feel you can take on the world! This is awesome, and you should enjoy that feeling of finally having the computer do what you want it to.

But don’t forget that you’re still just learning. You will still have so many concepts to learn, so many ways of improving your current code and this is, perhaps, a good time to start looking back at your old code and reflecting. Which parts of your code do you understand one hundred per cent, and what you would do better? Maybe it’s time for some refactoring as well?

05. Planning too much before writing code

Planning before jumping into writing code is a good thing, but when you over do something it ends up hurting you eventually.

Do not look for a perfect plan. Look for a good-enough plan, something that you can use to get started. Very often the business requirements change and that means your plan can be easily affected by that. Thus, don’t spend too much time on planning.

Writing programs is an ongoing process. Code is like a living organism. You will add features you have never thought about, you will remove features because of reasons you would never have considered. You need to fix bugs and adapt to changes. You need to be agile.

06. Messing with the master branch

I remember myself pushing code directly to master branch instead of creating PRs. As a result, when I needed to revert something was such a pain. The git history was pointless since there wasn’t any branch to checkout to. Essentially, we create branches so that we can roll back to an earlier version of our codebase.

Do not mess with the master. The master branch is deployable. It is your production code, ready to roll out into the world. The master branch is meant to be stable, never push anything to master that is not tested, or that breaks the build. Creating branches for new features and bugs should be non-negotiable.

07. Not writing tests

I admit that I belong to those who don’t like writing tests. However, I understand the importance of having your codebase tested. Although writing tests increase the duration of a project, it can become the savior for the future. Undoubtedly, it’s fine to test your code manually, but writing code to automatically perform the exact same interaction can save you to avoid bugs the next time you add more code to the project.

08. Not questioning existing code

When I am working to codebases that other people push code too instead of me I used to take it for granted that the code is good and the practice they used is the ideal one. I assumed that since the code is working it should be good. I was wrong.

Consequently, I was more inclined to repeat that bad practice elsewhere in the codebase because I learned it from what they thought was good code.

Indeed, some code looks bad but it might have a special condition around it that forced the developer to write it that way. Hence, this is a good place to wonder why this code was written in that way and which purpose serves.

09. Not being fan of code reviews

I used to fear the criticism that lies behind code reviews. This is a lie. If you feel that way, you need to change this attitude right away. Look at every code review as a learning opportunity. And most importantly, thank your reviewers when they teach you something. Code reviews are there only to make us better.

Sometimes, the reviewer will be wrong and it will be your turn to teach them something. It is a two-way interaction and the only goal is to make you both enhance your skills.

10. Not taking breaks

We are humans and our brain need breaks. I know that sometimes we can be really absorbed in the flow state and we forget to take breaks. It is always very helpful to leave the chair, take a short walk and think about what is the thing we need to do next. Coming back with fresh eyes always leading to resolving that bug you were dealing with.

This has been a long post. You deserve a break 😄