In this article, we are going to mention some of the mistakes so that we can all learn from them hoping that we can avoid falling for them again and again. The mistakes can be categorized as follows:
1. Mistakes at Preparation phase
2. Mistakes at Coding phase
3. Mistakes at Testing phase
4. Mistakes at Self Development phase
1. Mistakes at Preparation phase
- Trusting that the customer always knows what he needs
It's one of the most frequent mistakes. It should not always be assumed that a customer is fully aware of their real needs. Sometimes the client mixes what they really need to run their business as planned with what they want to have. You might ask: Why do I have to worry if the client understands their needs? I will eventually implement that request. The issue is that a confused client would still be a pain in your back. He kept coming back with more changes that sometimes needed a big shuffle. You believe this is right, never underestimate the power of frustration. Moreover, helping your client understand their needs would transform them into a loyal client.
- Missing the big picture
Sometimes a developer gets too concentrated on the small parts of the puzzle as he misses the big picture. It's not nice that the developer could miss a lot of details which are so important to solve the entire puzzle, or in other words, provide the right solution to the right problem. Therefore, the developer should always take a step back to have an overview to understand what is missing, how modules should interact and collaborate to play one consistent symphony.
- Reimagining the wheel
A developer should still explore its options. Sometimes what a developer wants to accomplish is already there, but it lacks it because it is motivated by the passion to implement what it 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, reusing an existing, well-established solution would likely be better and safer in the long term.
- Underestimating the workload
Sometimes a developer underestimates the amount of work a task should be carried out. This is very likely because of a lack of knowledge of the task itself. A developer should continue to break down tasks to the smallest possible size as long as he really understands every little 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 the code before performing an initial scan is a big mistake that some developers make. Most of the time, this happens because you are passionate about completing a task. Coding is a convenient area for many developers. Before jumping into the code there is a certain foundation to cover. A developer should be aware of the story associated with their task. You can't imagine how asking a few simple questions could save you ages of time and huge amount of stress. 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 of what the system requires, not what you can do. Several times in my career, I found such complicated systems that could have been implemented in a much simpler manner. From what I see, it sometimes happens that a developer keeps complicating matters by implementing what he knows if it meets his needs or not. If you're familiar with 10 design models, don't keep pushing yourself to implement them in your solution. You need to focus on what's right for you, think about it, analyze it, refine it, and finally start implementing it.
- Trying to ace all factors
In the software world, you can't get the best at every level. What's best for one aspect or factor could be worst for another and that's why you should always compromise. Therefore, you need to define your priorities, rank them and start working out the best solution you can find for server your needs accordingly.
2. Mistakes at Coding phase
- Hiding issues instead of solving them
Sometimes developers tend to find the shortest way to solve a problem and, unfortunately, they end up hiding it instead of correcting it. It's like when you have a field that is not defined at a certain time and to fix it you continue to define it in many locations. Yes, you might end up with the field being put in as it was intended in the first place, but in fact, you might be on top of a catastrophe coming soon. Before solving a problem, you first need to find the root cause so that you are sure you are fixing the right problem in the right way.
- Ignoring logging
Logging is one of the most important things that every developer should pay attention to.That's the kind of thing you never miss until you're in a real mess. I noticed that many developers tend to ignore connecting to their software modules thinking that this is a waste of time. However, they learn the lesson to their own detriment when their modules fail in production.
- Workarounds
Applying workarounds in your code to resolve a problem or quickly apply a change would respond in the future, perhaps earlier than 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 consider the impact of what you change in your code, stay focused on the task, but also keep in mind the overall solution design.
- Too many responsibilities
One of the errors of a developer is to inflate its modules with too many responsibilities. This makes the whole system fragile. Every module should be responsible for its main role. If you find that your module does too many things that don't belong to it conceptually, this should be an indicator that something isn't right. Dividing your system into small, well-defined modules is a skill that you earn over 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's not something that directly affects your deliverables, but keep in mind that your code would be processed by other developers. Therefore, even though you have no problem with formatting your code, other developers might have it. So, please try to make it easy for you to read your code.
- Describing the obvious
What I am talking about at the moment is adding comments that have no added value. Your comments should provide information that is not obvious based on the code. So adding fake comments would not help and moreover it could 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 the commented code hanging around afraid to lose it when they need it in the future. This is a bad practice, since the code ends up being inflated by too many distractions. Also, if you use version control systems, and you should, you can always return to the removed code whenever you want.
- Writing confusing commit messages
Often 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 will understand what your commits are. This is important as it also makes it easier to track old commitments and deliveries.
- Enormous commits
One of the big mistakes that some developers make is making big changes in a single commit. It is therefore difficult to track and review changes. Always try to split your commits into small unique units so that each commit is linked to a small portion of your changes. This would greatly facilitate review and tracking and facilitate the use of these commitments in the future for duplication and cancellation.
3. Mistakes at Testing phase
- Discard automated tests
Today, software systems tend to be big and tricky. Thus, based on manual tests only would be a huge mistake because your system would not be robust enough against quick changes. That's why you should always consider automated testing to make sure that all your company's rules are covered by automated testing. This would make your system stronger against unexpected failures and quick changes.
- Embrace the happy screenplay
Testing is good but you have many scenarios to cover. Covering the happy scenario might be a good first step, but that's not the end. You should always spend time and effort defining your business rules and their associated test scenarios prior to moving into implementation. This would help cover all of the base cases, corner cases, and complex scenarios.
4. Mistakes at Self Development phase
- Fear of making mistakes
Never be afraid of making mistakes, as it will limit and prevent you from learning and exercising. You'd make mistakes and that's all right. It's all about learning from mistakes and making sure you don't repeat them. And if you do it again... Again, try to learn again and this time consider why you could not protect yourself from falling into the same mistake again. Learning is an ongoing long journey, so do your best to make the most of it.
- Believing you are always right
You don't always get it right. Don't be stubborn, be open to listening to others, learn from them, reassess how you think and make decisions. That would eventually help you grow.
- Not taking care of your health
You're a human, not a robot, not a computer. Your health is your own fuel, so try to keep him healthy. That’s it.
- Underestimate its own development
You should always come up with a plan for your personal development. You need to learn new things and develop competencies. In the software world, there is something new each day. Standing still is actually the same as stepping back. My advice is to come up with a plan, plan it and follow it. This would help you a lot in setting measurable goals to achieve.
- Fear of asking for help
Some developers think that seeking help from others is a sign of weakness that is wrong. As we said earlier, nobody knows everything, and you wouldn't be right all the time. Therefore, asking someone for help should not make you feel or look bad, it is the natural way to share and transfer knowledge.
- Premature asking for help
On the other hand, some developers are quick to ask for help before investing enough time and effort to try to find answers to their questions. As we said, you shouldn't be ashamed to ask for help, but part of your role and your job is to find answers to your own questions. This would help you progress and acquire analytic skills. Otherwise, you would always depend on another person. It's worth mentioning there, you should always time-box it. In other words, don't delay in finding the answers on your own. Be reasonable on this.
- Not sharing knowledge
As we said, you should not be afraid to ask for help, you should also provide help when you can. It's a win-win for everybody. Helping someone would help you increase your knowledge and help them learn. So my advice is always 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 a few of the most common errors developers make. You might identify with some of them or not, but in the end, it would still be nice to keep them in mind.
Finally, I hope you liked reading this article the way I liked writing it.