Do not forget: your number one enemy as a software developer is technical debt.
If you have been programming for a short time, congratulations: what you are about to read may save you thousands of hours of work and make your professional career better over time.
One thing I have always liked about programming is that software development has subtle aspects that are difficult to understand at first until you experience them yourself.
Perhaps a good learning method is to make every possible mistake and then realize the solution, although unfortunately, in a company context, that means lost income, failed projects, and likely a search for a new job.
Over time and with experience, you accumulate a certain wisdom and already know in advance the long-term consequences of doing something one way or another.
Imagine what would happen if, for a month, nobody took care of picking up, organizing, and cleaning the kitchen of your house. On the first day nothing would happen; on the second, preparing a simple sandwich might already be annoying, but after a week, the kitchen would be a dirty and impassable space. It would still be a kitchen, but doing anything in it would cost more and more effort (besides being disgusting, of course).
Well, many times we let our project grow in that way (or we are forced to do so in an irregular work dynamic, for “the day before yesterday” and amid great disorganization). Almost without noticing it, we gradually leave stones in the path that become rocks until we can no longer walk through it.
A naive and inexperienced mind might think: if this already works, why bother? Ignoring that “what already works” will still need more functionality added or the existing one modified.
Technical debt arises from a very common mistake among programmers, especially beginners: programming is not just writing lines of code and that is it.
Yes, read the previous sentence again.
What do I mean when I say “programming”?
It rarely happens that what you do on the first attempt is something perfect that never needs to be touched again; even less so in the context of a project that almost always grows with requirements you cannot even imagine yet.
That means you have to program so that the lines of code you write can be modified later.
That act of “modification,” whatever it is for, is also programming.
Does what you made work? It might. But how do you ensure it keeps working later when the project grows? By creating tests, of course. Programming also means developing a battery of tests that cover most of your code.
Does your project have the best possible design? Unless you are a very experienced developer, it is normal that initially the design does not even cross your mind; you simply add functionality however you can and that is it, especially when deadlines are tight and you want to get home soon (a typical case where files with hundreds of lines of code appear = lack of design).
However, without design, your application is like a building whose foundations, beams, and columns are made of clay.
Design is the structure of the application that allows you to add functionality and maintain it in an orderly and efficient way (in the least time possible). A good design works like a blueprint or guide that helps you understand the application better.
Designing, or improving the existing design, is also programming.
As an application grows, we necessarily complicate it; that is why “simplifying” is essential for that growth to be orderly. Simplify what? Function names, algorithms, extracting common functionality, making a loop easier to read, etc. It is not enough for you to understand the code; you have to make it understandable to any other person with the least effort possible.
You have to program so that others can take on what you do with ease.
All of this should form part of our “programming” time. Too many times I have seen applications where the business logic is entirely in a single class with thousands of lines and a programming style that only its author is likely to understand.
Not respecting all of the above, and similar considerations, means adding the stones in the path we were talking about before. Those stones are the debts that accumulate inevitably until you realize that adding more functionality, modifying the existing one, or debugging an error is increasingly difficult, if not impossible.
Your job as a programmer is to reduce technical debt as much as possible. It is inevitable because it is intrinsic to software development (another phrase you may need to read again).
In fact, I claim that part of the development cycle of an application should consist of detecting it and improving any aspect of the project. Surprisingly, that creative activity of improvement takes less time than we think and is very rewarding—at least for me.
Those improvements can be micro-improvements that, in a kaizen way, over time produce major positive changes in the application.
(Excerpt from one of the chapters of the book “Legacy Code: How to modernize inherited code or software projects that have grown too fast in fourteen steps,” available from December 5 on all platforms).
