7 common mistakes that software developers do

As technology continues to rapidly advance, software development has become an increasingly important field. However, with the increasing complexity of software development, there are also many common mistakes that developers can make. These mistakes that seem trivial initially but have serious consequences in the longer run. In this article, we will explore some of the most common mistakes made by software developers, and provide tips and strategies for avoiding them.

• Naming Convention : Not paying attention to the naming convention is the first mistake every developer make in the beginning. They keep on adding functions/methods with name as whatever comes in mind first and then when the product expands or when a new person joins the team nobody has the clear vision as where to find a particular functionality or issue which negatively impacts the timeline
• Code Duplicity : It is a by-product of not following the proper naming convention as when the developer tries to add some feature in the product then (s)he keeps on adding the new methods as per need as (s)he doesn’t know whether this method is already available or not. When there is a need to make some change in the method then it has to be done in both methods which again negatively impacts the timeline
• Improper Logging : Not logging the requests and responses is one of the most common mistakes. Some developers feel lazy to add logs and some find it costly to add logs :P but the truth is if you don’t add proper logs then you waste your golden time in debugging issues by creating random scenarios about what might have happened that lead to the issue. Logs should be added at the start and the end of the method as what input comes in the method and what goes out from it. But be mindful of what you are logging. Don’t log user’s personal information as it might be against the regulations and do use the unique IDs or identifiers to help filtering the issue otherwise logging is not of much help
• Comments : This is an arguable point as some would say we should add comments and some would say we shouldn’t as code should be self explainable but I would suggest we should add a little bit reference why we are adding something there. Suppose we are sending a user list in the response that is quite understandable through the code but if you are doing some manipulation like if a user has this feature then it is a priority feature and should be on the top of list(this is a business requirement and the person who haven’t worked on this piece of code could know this) so it should be commented as to why we are doing this so that other person might not remove or modify it by considering it an unnecessary processing
• Commented Code : Sometimes a feature becomes obsolete and is of no use anymore. Instead of deleting it, some developers comment the code and keep it as such in the hope that it might be of some help. Please have faith in your ability and remove that code instead of only commenting it. If you can write it once, you can write it again. 99% chances are that you won’t need that again and if that is needed again and again then add a feature flag and control it using DB. If you are writing a new version of an API and can’t delete the previous version then do mark the API as deprecated so that other teammates can know that a newer version is available and then slowly remove it’s dependency.
• Modular Code : Some developers have the habit of putting all the logic in a single method. It leads to problems of code maintenance and code duplicity. Remember, a feature can be broken into 4 parts — fetching, validation, processing and output and there should be different methods for each part which then can be called in a single method. Fetching and validation methods are usually generic one and can be used by other features as well. So writing a modular code helps in the re-usability of code and easy maintenance.
• Handling Exceptions : This mistake is something that sometimes even experienced developers do. In broader terms, it can be called as directly handling the exceptions and not understanding their root cause. For example : handling 4xx and 5xx errors as same. 4xx errors are API level errors which are related to data issues i.e. either the data validation is failing or data format is wrong so it can’t be retried with the same data. So for this simply throw this error with proper error message. 5xx errors are due to server issues like server is down and can be retried for the same data so proper retry mechanism can be added for them with exponential cool off period if retry is needed for them.

I have tried to capture all the common mistakes that I encounter in my daily life but it is not an exhaustive list. Please do share your views and mistakes that you have encountered in the comments below.