Often, developers, especially junior ones, tend to focus on improving the technical quality of a project by critiquing existing solutions left and right. At first glance, this may seem like a professional approach and a good strategy to impress managers, but it’s not always the case. Here’s why.
Understand business needs
When trying to understand the reason for a solution, it’s worth not only looking at the code itself but also think about the developer who worked on this functionality and the limitations they had.
Let’s imagine you’re working on a new, fancy project. After weeks of development and testing, it’s finally ready for release. Everyone is eagerly anticipating it.
But suddenly, your boss comes up with the idea of an additional, highly important feature that is crucial for the success of the entire business. And it absolutely must be included in the current release.
But the issue is that you can’t push the release date too far and delay the launch significantly. Your competitors aren’t going to wait much either. So, you decide to implement the bare minimum, saving time by not working on the edge cases, omitting some programming best practices, and using less efficient approaches.
Does this make your code bad? Well, most people would say «Yes». But does this make the solution wrong or shows you as a bad programmer? Absolutely not.
By doing so, you demonstrate yourself as a true professional, prioritizing business needs.
This is an extreme example, but it perfectly illustrates why you should always keep in mind the limitations you have. Of course, you should not forget to properly track the technical debt created by such an approach.
But this isn’t the only reason to look at your «bad» codebase from a different perspective.
Everything will eventually become a legacy
Have you ever heard a funny story about a programmer who opens a project they worked on just a couple of months ago and finds themselves unable to understand what’s going on? If not, you might not have spent enough years in programming (or perhaps you’ve just not wasted too much time on programming memes 🙃 💻).
But the funny thing is, it’s actually true - everything you write will become a legacy pretty soon.
Just don’t forget about this while polishing your new module/function/class/etc. Focus on making your code easier to understand and maintain rather than on applying a new pattern you learned a couple days ago.
Just remember this when you’re refining your new module, function, class, or any other part of your codebase. Focus on making your code easier to understand and maintain rather than on implementing a new pattern you learned just a couple of days ago.
At least, unless you want to damage the project you work on.
Think about maintenance cost
Is a more complex CI/CD solution with a handful of third-party tools beneficial for the project? And should you consider adding an additional library to reduce the codebase size by two percent?
There is no single answer, of course. But you should always consider that every new dependency increases maintenance costs. That’s why it’s a good idea to test out new libraries or tools in one of your pet projects or sandboxes first.
The primary benefit for businesses in adopting existing solutions is the possibility to reduce the amount of work required in implementation and support. This also includes the time required for the onboarding process of a new developer.
There’s no reason to use a tool if it only saves you a day but takes a week to learn how to use it for your specific case. So, please, choose your tools wisely.
Higher complexity can also lead to a higher number of bugs 🪲 in your software.
My Conclusion
Of course, there are a lot of different projects where each one has its own limitations and specifics. Every technical solution should be based on a proper investigation.
Do not try to make everything perfect - make it optimal.
Thank you for reading! 🎉