Regardless of how beautiful and well designed a house is, if the foundations are weak it’s just a matter of time before you start seeing cracks and leaks all over the place. And if you ever want to remodel or expand it, you might end up spending time and resources fixing the foundations before any work can be done.
An astute reader will have already figured out that I’m not really talking about real estate development but rather about the similarities between house construction and app development. While users get to interact with the frontend of an application, it’s actually the backend that’s doing the heavy lifting. That’s why collaborating with the best backend engineers possible is essential.
Of course, a lot goes into being a good backend developer. It’s not enough to have a good handling of a framework, to meet the demands of modern markets a backend aspirant should have at least a good handling of:
- Data structures and algorithms
- Databases and data models
- Several frameworks (and the respective programming languages they are based on)
- Cloud hosting (AWS, Google Cloud, or Azure)
- Server architecture
- Dockers
On top of that, they have to work under pressure to meet deadlines and to refactor, debug or rescale on the fly. There is a lot to handle, and some of the most common sins backend developers make can have long-lasting consequences. Let’s review the 6 most important ones.
#1 You shall not accumulate too much technical debt
The first sin is common to both backend and frontend developers: having a significant technical debt stack. Agile teams indeed rely on technical debt to provide faster solutions and to deliver better products, but odds are that the more you accumulate, the higher the chance that it will be harder to implement new solutions or scale the project later on.
The maxim here is, don’t build code on top of bad code, as once you get to refactoring the new code will probably break. Spaghetti code, long functions/methods, too many indentations, excessive if/else statements, and bad variable naming practices may seem like small details with insignificant consequences, but they can build up to heaps of trouble.
With good coding practices and good planning technical debt can be avoided, and in those cases where it’s necessary, a good protocol to keep track of it will go a long way in preventing the team from building a mountain on top of a house of cards.
#2 You shall not write poor documentation
Good documentation is like a well-drawn map or a good recipe: it leaves nothing to the imagination. To take a page from the zen of Python, explicit is better than implicit. In that sense, one of the greatest sins for backend developers is to think of documentation as an afterthought.
Poor or missing documentation will lead to confusion in the best of cases or will outright stop a project in its tracks as developers will have to manually review the code line by line to figure out what’s going on.
With good documentation practices, frontend developers will have an easier time grasping how their side of the project will communicate with the backend and those that come after will have a reliable source of information to fall back on when hunting for bugs or when restructuring.
As a bonus, we can add another commandment: you shall comment your code. Much like clean documentations, commented code will help code reviewers and other developers understand the underlying logic. These comments can even help the developers themselves when they go back to review a code they haven’t touched in a while.
#3 You shall not miss tests
Tests are an integral part of any development cycle. Writing tests and aiming for edge cases helps backend developers spot bugs and explore scenarios that might otherwise go unnoticed until it’s too late. Yet, some developers choose to skip some tests, maybe because they want to meet a tight deadline or because they are overconfident.
Thus, this sin often happens when developers run out of time or when they rely too much on their own judgment/code reviews. No set of eyes is experienced enough to predict the behavior of a code in all possible situations.
A simple way to avoid this issue is to write the tests alongside the code or to share pseudo-code with another developer and have them write a set of tests. In fact, some teams go as far as to first create the most extreme tests possible and then write the code. In that way, they are effectively developing to solve edge cases.
Tests are a reliable way to be certain that the code is working as intended and that the logic behind it is flexible enough to adapt and scale as required by the project.
#4 You shall not use many technologies for the same solution
One of the greatest assets of working with popular programming languages like Python or node.js is the amount of resources available. So, why write something from the ground up when you can just import it?
But that opens the door to its own set of problems. Relying too much on external software and libraries means first and foremost that you are dealing with several APIs at the same time, and that’s in itself is already a challenge.
But, aside from that, technologies get constantly updated, which may bring unintended changes or bugs that may break your own project. Also, projects get deprecated, and that amazing library you found may suddenly disappear in the blink of an eye.
That’s not to say that one should stick to one solution, but rather it’s a word of caution that introducing new technology to a project should always be a well thought out decision and that sometimes walking that extra mile of doing it yourself will save headaches down the line.
#5 You shall not forget a backup protocol
Almost every backend developer has to deal with databases in their careers, and as we all know, if an app is a body, then the data is the blood that gives it life. Good backend developers keep extensive backups of their data, in the cloud, in physical media, in remote servers, pretty much everywhere. Without them, engineers risk losing their entire work over a hardware or software mishap.
That’s why backups should be frequent and reliable. If your data is getting updates on a minute-by-minute basis, losing a couple of days could be catastrophic for a project. It’s better to invest in a storage solution than to lose everything with one mistake.
#6 You shall not have poor planning before building the data model
Rebuilding a model from scratch can be a nightmare, so getting it right the first time around will save the project time and investment. Sometimes restructuring data models is unavoidable, but let those times be the product of outside influences instead of a lack of foresight.
Good backend developers get a very clear picture of what the project is supposed to do, and will design a model that fits the project with scalability in mind, even if the project does not involve scaling anytime soon.
Designing a good data model is an excellent example of long term planning and will avoid the problems that come with databases that overextended their capabilities.
A good backend developer is a strategist and a team player
Technical skill isn’t the only thing a backend developer needs to be good. What really makes an expert shine is that they understand the role they have in the development team and how much the project depends on their work. Hiring a good backend developer might just be the difference between a house that can withstand a hurricane and one that falls apart in a windy season.
