Who Gets to Decide What “Good Practices” Are?

Good practices are great but knowing who decides them and where they come from is better. It is no secret that when you fully understand what you are doing, you immediately feel better and more comfortable. The same thing applies to good practices. Why should you believe without question these precepts decided by people you do not know and who have never collaborated with you on your project?

You could say that the people dictating these principles have more experience than you and know this world better than you do. Two things. First, maybe one day you will have more experience than they do. Maybe you will be better. Maybe you already are. Second, years of experience are not everything. It is common to see developers with 20 or 30 years of experience who are completely out of date or with habits from the last century. Years of experience can be an argument, but not the only one. Computing evolves at an exceptional speed...

Who decides these things anyway?

One thing we are going to see is that you should always question “good practices” and never consider them as a general truth that you must respect without understanding why. One excellent way to improve yourself is to ask every time you do not agree with someone’s review or point of view. Developers are fascinating as they can find unlimited ways to solve a single problem—unlimited solutions for the same result. Even if this can be seen as something a bit tiring sometimes, it is always interesting to understand why a developer wants to solve a problem in a different way than you. There are multiple goals to this, as follows:

• You will improve your communication skills: If you want to communicate and be understood, you will have to explain your problem clearly.
• You may learn new ways of doing things: We are all using the same language, but we all have different experiences with it. These different career and life...

Best practices – where do they really come from?

When we are talking about “best practices," we can differentiate three cases, as follows:

• Principles that have been proven for decades to work, which also are deduced from common sense: In this category, we can—for example—find design patterns. In short and if you do not know them, these are tools that fix recurrent programming problems. They have been here for decades and are known by millions of developers.
• Choices made because we had to make them: Here, we can find things such as code style, naming conventions, and so on. Technically, it does not matter if you would like to use camelCase or snake_case to name your files. But if everyone is following the same rule, it is easier for everybody to understand each other.
• “Technical” best practices: Some “best practices” are actually dictated by technical constraints and features. A concrete example is “...

Being context-aware

Here, we enter one of the most important parts when we talk about clean code. If there were only one thing to remember, it would be this. We may regularly talk about the rules defined by other developers, object principles, and the principles of clean code, but nothing will ever be as good as what we are going to talk about here: it is about being aware of your context. One thing that is missing from many books and articles about clean code is the feeling that it is relevant to everyday life. A developer’s life is made up of unexpected events, technical constraints, impossibilities to do some things, or being forced to do some other things.

There are as many ways of doing things as there are projects. Each project has its own history, technical decisions, and constraints. As a result, we end up with many theoretical principles that are not applicable or that would break the coherence of the project. Good practices may dictate how you name variables, how...

Being consistent – get results quicker

Being perfectly consistent in what you do will force you to understand what you are doing. Then, everything will become a habit. If you have these good habits to the point that they have become natural to you, results will come faster in two specific cases, as outlined here:

• As we have seen from the beginning, you will be able to understand each other much faster within your team—developers will have the same habits. More rarely, but it can happen: you will sometimes have to discuss code or show things to non-technical people in your project. Although these people—such as a product owner, for example—may have some basic technical knowledge, it is best to assume that you will need to go back to the most basic basics. You will have a much easier time explaining a complex and technical subject to someone non-technical if you have done things simply, cleanly, and without hesitation in your work.
• The second case...

Summary

We have just seen a lot of new knowledge together. If you understand it, you can be sure that you are already a better developer than you were in the previous chapter.

Knowing the SOLID principles is a real asset in the professional world and in industrial-quality projects. Even if each case is different and each project has its specificities, these principles have the advantage of being applicable almost everywhere, and at least of being very strongly inspired by them.

Keeping in mind the KISS, DRY, and YAGNI principles will allow you to keep your feet on the ground and not spread yourself too thin during your next developments. They emphasize thinking about the present moment to help prepare for the future, rather than thinking about the future to try to adapt to the present moment. You should definitely remember this. We don’t know the future constraints that will be imposed on us, whether technical or functional, so it makes more sense to think about how to...