Subscribe to get best practices, tutorials, and many other cool things directly to your email inbox

Ahmed Tarek
- Feb 22, 2022
- 9 min read

Mistakes Made By Developers

Updated: Apr 17

These are the most common mistakes made by developers.

The most common mistakes made by developers. Code Coding Programming Software Development Engineering Architecture Best Practice — Photo by krakenimages on Unsplash, adjusted by Ahmed Tarek

There are some common mistakes which almost all developers have made at some point of their career days.

In this article, we are going to mention some of these mistakes so that we can all learn from them hoping that we can avoid falling for them again and again 🙂

The mistakes would be categorized in more than one category as follows:

📛 Mistakes at Preparation phase📛 Mistakes at Coding phase📛 Mistakes at Testing phase📛 Mistakes at Self Development phase

In the next sections, we would go through the mistakes done through each one of these phases. So, buckle up and enjoy the ride.

Mistakes at Preparation phase

📛 Trusting that the customer always knows what he needs

This is one of the most common mistakes. You should not always trust that the customer is fully aware of what he actually needs.

Sometimes the customer mixes between what he actually needs for his business to work as expected and what he wants to have.

You might ask:

Why should I care if the customer understands his needs? Eventually I am going to implement what he asks for.

The problem is that a confused customer would always be a pain in your back. He would always come back with more changes that could sometimes need huge refactoring. You think it is ok, don’t ever underestimate the power of frustration.

Furthermore, helping your customer understand his needs would turn him into a loyal customer.

📛 Missing the big picture

Sometimes a developer becomes too focused on the small parts of the puzzle that he misses the big picture.

This is not good as the developer might miss a lot of details that are so important to solve the whole puzzle, or in other words, deliver the right solution to the right problem.

That’s why the developer should always take a step back to be able to see the big picture, understand what is missing, how modules should interact and collaborate to play one consistent symphony.

📛 Re-inventing the wheel

A developer should always explore his options. Sometimes what a developer wants to achieve is already there but he is missing it because he is driven by the passion of implementing what he has in mind.

As a developer, you should always check if what you really want to implement is already implemented somewhere, may be in the same solution, or in a third party or somewhere else. If this is the case, most probably re-using a well established existing solution would be better and safer on the long run.

📛 Underestimating the workload

Sometimes a developer underestimates the amount of work that a task would need to be completed. Most probably this happens due to a lack of knowledge of the task itself.

A developer should keep breaking down tasks to the smallest possible size to the extent that he really understands each small task and its requirements, then he should be able to put an estimate for each of these small tasks.

The estimate should include all the activities to be held to fully deliver the task including the following:

▶ Designing

▶ Refactoring

▶ Implementing

▶ Covering with automated tests

▶ Testing

▶ Processing code review comments

▶ Updating documentations

▶ Signing off

Dropping any of these might cause an unexpected delay.

📛 Premature coding

Jumping into code before doing any initial analysis is a big mistake that some developers make. Most the times this happens due to being driven by passion to finish a task. Coding is the comfort zone for many developers.

Before jumping into code there are some basis to cover. A developer needs to be aware of the history related to his task. You can’t imagine how asking some simple questions could save you ages of time and enormous amount of effort.

Therefore, my advice to you as a developer is to always do your analysis first and believe me it would pay off.

📛 Over-engineering

Always think about what the system needs, not what you can do. Many times in my career I came across so complicated systems which could have been implemented in a much simpler way.

From where I see it, sometimes a developer keeps complicating things by implementing whatever he knows whether it suits his needs or not. If you know like 10 design patterns, don’t just keep pushing yourself to implement them in your solution. You need to focus on what serves your needs, think about it, analyze it, refine it, and finally start implementing it.

📛 Trying to ace all factors

In the software world, you can’t achieve the best in all aspects. What is the best for some aspect or factor could be the worst for another and that’s is why you would always have to compromise.

Therefore, you need to set your priorities, rank them and then start working on finding the best solution you can come up with to server your needs accordingly.

Mistakes at Coding phase

📛 Hiding issues rather than fixing them

Sometimes developers tend to find the shortest path to fix an issue and unfortunately they end up with hiding it rather than fixing it.

It is like when you have a field which is not set at a certain moment and to fix it you keep setting it in many places. Yes, you might end up with the field being set as it was expected in the first place but actually you might be overlooking a disaster to come shortly.

Before fixing an issue, you first need to find the root cause so that you are sure you are fixing the right issue in the right way.

📛 Ignoring logging

Logging is one of the top most important things that every developer should pay attention to. It is that kind of things which you don’t miss until you are in a real disaster.

I noticed many developers tend to ignore logging in their software modules thinking that it is a waste of time. However, they learn the lesson the hard way when their modules fail on production.

📛 Workarounds

Applying workarounds in your code to fix an issue or quickly apply a change would fire back in the future, may be earlier than what you think.

As we said before, when you are working on fixing an issue or applying a change you become too focused on the small details to the extent that you miss the big picture.

Always think of the impact of what you are changing in your code, stay focused on the task but also keep in mind the whole solution design.

📛 Too many responsibilities

One of the mistakes a developer makes is bloating his modules with too many responsibilities. This makes the whole system fragile.

Every module should be responsible for its main role. If you find your module doing too many things that don’t conceptually belong to it, this should be an indicator that something wrong is happening.

Dividing your system into well defined small modules is a skill you gain by time and it would always pay off.

📛 Using magic numbers

Don’t get me started on magic numbers. It is a nightmare to come true.

If you think a module should make use of some constant number, don’t just hide the number somewhere in the code. Instead, it should be well defined in a place visible to all contributors so that it is sound and clear.

Furthermore, check if this number could be defined as a high level constant defined within a system constants module. This way it would be more visible and maintained.

📛 Messy code formatting

Yes, I know it is not something that affects your deliverables in a direct way, but, keep in mind that your code would be processed by other developers.

Therefore, even if you don’t have any problems with your code formatting, other developers might have. So, please try to make it easy on everyone to read your code.

📛 Describing the obvious

What I am talking about right now is adding comments which don’t have any added value.

Your comments should be providing the info which is not obvious from the code. So, adding dummy comments would not help and furthermore it might confuse other developers.

Additionally, worth to mention here is that if you follow the concepts of clean coding you should not be in that need to describe what your code is doing using comments.

📛 Leaving commented code blocks

Some developers keep commented code laying around out of fear of losing it when they need it in the future.

This is a bad practice as the code ends up bloated with too many distractions laying around. Beside, if you are using version control systems, and you should, you can always get back to the removed code whenever you need.

📛 Writing confusing commit messages

Many times when I explore a pull request I find bad commit messages that not only don’t help me understand, but also confuse me.

Your commit messages should be descriptive so that any other developer could understand what your commits are about. This is so important as it also makes it easier to track old commits and deliveries.

📛 Enormous commits

One of the big mistakes that some developers make is committing big changes into one single commit. This makes it so hard to track the changes and review them.

Always try to divide your commits into small single units so that each commit is related to a small part of your changes. This would help so much with the review and tracking and also would make it easy to use these commits in the future for duplication and reversing.

Mistakes at Testing phase

📛 Ignoring automated testing

Nowadays software systems tend to be big and complicated. So, depending on manual testing only would be a huge mistake as your system would not be robust enough against rapid changes.

That’s why you should always consider automated testing so that you make sure all your business rules are covered with automated tests. This would make your system more robust against unexpected failures and rapid changes.

📛 Embracing the happy scenario

Testing is good but you have many scenarios to cover. Covering the happy scenario could be a good start but it is not the end.

You should always invest time and effort in defining your business rules and their related test scenarios before jumping into implementation. This would help you cover all the basic, corner cases, and complicated scenarios.

Mistakes at Self Development phase

📛 Fear of making mistakes

Don’t ever be afraid of making mistakes as this would constrain you and hold you back from learning and practicing.

You would make mistakes and this is fine. The important thing is that you learn from your mistakes and make sure you don’t repeat them. But, what if you repeat them?… still, try to learn again and this time think of the reason why you couldn’t protect yourself from falling into the same mistake again.

Learning is a long running continuous journey, so do your best to enjoy it.

📛 Believing you are always right

You are not and would not be always right.

Don’t be stubborn, be open to listening to others, learn from them, re-evaluate your way of thinking and decisions. This would eventually help you grow.

📛 Not taking care of your health

You are a human, not a robot, nor a machine. Your health is your own fuel so try to keep it in good shape. That’s it.

📛 Underestimating self development

You should always make a plan for your self development. You need to learn new things and gain skills.

In the software world, everyday there is something new. Standing still is actually equivalent to moving backwards.

My advice to you is to put a plan, schedule it, and follow it. This would help you so much setting measurable goals to achieve.

📛 Fear of asking for help

Some developers think that asking others for help is a sign of weakness which is wrong.

As we said before, no one knows everything and you would not always be right. Therefore, asking for someone’s help should not make you feel or look bad, it is the normal way of sharing and transferring knowledge.

📛 Premature asking for help

On the other hand, some developers hurry for asking for help before investing proper amount of time and effort in trying to find answers to their questions.

As we said, you should not feel ashamed of asking for help, but, a part of your role and work is to find answers to your questions yourself. This would help you grow and gain analytical skills. Otherwise, you would always be dependent on someone else.

Worth to mention here, you should always time-box it. In other words, don’t take forever to find the answers yourself. Be reasonable about it.

📛 Not sharing knowledge

As we said that you should not be afraid of asking for help, you should also provide help whenever possible.

It is a win-win situation. Helping someone would help you solidify your knowledge and would help him learn.

Therefore, I would always advise you to share your knowledge and help others grow.

Final Thoughts

We all do mistakes but what really makes a difference is whether we learn from them or not.

In this article I shared some of the most common mistakes that developers make. You could relate to some of them or not, but, at the end, it would always be good to keep them in mind.

Finally, I hope you enjoyed reading this article as I enjoyed writing it.