10 mistakes I made when I started programming

1. Self-doubt

This feeling is something anyone can have, and it applies to every aspect of life. Self-doubt is the number one mistake you can make as a beginner programmer. When you think you’re not good enough or smart enough, you’ll never achieve what you’re aiming for. Anyone can learn to program to at least a basic level if they stick with it.

Code seems daunting at the beginning, and you’ll probably think this isn’t for you. That’s normal. But day by day, with daily practice, you learn what each part does. It stops feeling scary, it starts making sense, and you start seeing how things connect. Some people grasp algorithms quickly and write good code sooner than others, but without hard work and hours spent coding, tutorials and books won’t reach their full potential.

2. Not linting my code

Want to know if the code was written by an experienced programmer? You should see well-formatted code with consistent indentation and 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.

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.

3. Poor variable and function names

I used to name variables and functions with whatever I came up with when writing code. That was a huge mistake. One of the best indicators that the code you’re working on is clean is when the function turns out to be what you expected. Naming variables as descriptively as you can is one of the first and most important ways to create code that feels expected.

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

4. Belief of knowing it all

After some days or months of persistence and hard work, you start seeing results. Your confidence grows, you feel powerful knowing the fundamentals, and you feel you can take on the world. That rush feels good, and you should enjoy the moment when the computer finally does what you want.

But don’t forget that you’re still learning. You still have many concepts to learn and many ways to improve your current code. This is a good time to look back at your old code and reflect. Which parts do you understand one hundred per cent, and what would you do better? It’s time for some refactoring, too.

5. Planning too much before writing code

Planning before jumping into writing code is good, but when you overdo something, it ends up hurting you eventually.

Do not look for a perfect plan. Look for a good-enough plan; something you can use to get started. Requirements change, and your plan changes with them. So don’t spend too much time planning.

Writing programs is an ongoing process. Code is like a living organism. You’ll add features you’ve never thought about; you’ll remove features for reasons you’d never have considered. You need to fix bugs and adapt to changes.

6. Messing with the master branch

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

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

7. Not writing tests

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

8. Not questioning existing code

When working on codebases where other people push code, I used to take it for granted that the code is good and the practice they used is ideal. I assumed that since the code works, it should be good. I was wrong.

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 there may be a special condition around it that forced the developer to write it that way. This is a good place to wonder why this code was written that way and what purpose it serves.

9. Not being a 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 brains need breaks. Sometimes we get absorbed in the flow state and forget to take them. It helps to leave the chair, take a short walk, and think about what you need to do next. Coming back with fresh eyes helps you solve the bug you were dealing with.

This has been a long post. You deserve a break :)