GUILTY programmer

In my opinion, every programmer that has at least a few years of coding experience should know how to write clean code. However, just knowing how to write clean code doesn't mean that it will be applied consistently.

But what's the reason? If you know how to write clean code, why aren't you doing it?

There can be various reasons. In this article I will attempt to address some of the justifications that I encountered during my practice.

JUST MOVED TO THIS TEAM

Being new in the team and unfamiliar with the project can make a programmer feel unconfident. The programmer can identify obvious issues in the code but refrain from fixing or raising them due to feeling unconfident in the new team and project. As a result, new lines of code are added to already poor quality code, exacerbating the problem.

It is important to note that this behavior does not apply to everyone, as it largely depends on an individual's character.

On the other hand, there are also types of programmers who, upon joining a team, immediately start making appropriate and inappropriate criticisms of the code, starting from day one.

WON'T TOUCH WHILE WORKS

It's not uncommon for programmers to have to work on parts of legacy code, where the inner workings are unknown or unclear and there is nobody available to explain it.

Although it's obvious that the code needs to be improved, programmers usually don't do that because they are afraid that changes will affect other parts of the program and will break the whole application.

In this case, it would not be fair to criticize the programmers as their concerns may be valid.

Decision about improving the code or leaving as it is (or even making it worse) may depend on various factors.

For example:

• Knowledge: Often, legacy code utilizes old technologies, languages, and libraries. To improve such code, a complete understanding of it is necessary, and mastering those old technologies is required to understand it.
• Deadline: Does the programmer have enough time to improve the code ?
• Testing: Will enough resources be provided for regression tests?

THE LAST WEEK

Based on my experience of switching several companies, I can confidently say that during the last working days, there is a lack of motivation to do anything related to the work.

However, this does not justify poor quality code being written by programmers during the rest of their days in that company, just because they have submitted an application for dismissal.

Firstly, it is disrespectful to their teammates, as they will have to fix all the issues caused by the poor quality code.

Furthermore, in general, it shows a lack of professionalism and basic human decency of that person.

NO CODE REVIEWS

There are cases when the team does not conduct code reviews at all, and everyone writes their code in their preferred way.

As a result, the quality of the code relies entirely on the conscience of the programmers, and as experience shows, not all team members possess a strong sense of responsibility. Most of them don't spend a little more time to write clean code, instead they think "Well, the important thing is that it works, there is no desire to write so thoroughly."

OVERCONFIDENCE

The quality of the code also depends on one more factor.

There are programmers that overestimate their experience and knowledge, resulting in inconsistent code compared to their teammates.

It can be expressed in different ways.

For example:

• creating a new method instead of using existing one
• integrating a new library instead of using already integrated alternative
• not following common rules (naming convention, files structure etc.)

I'M BEING RUSHED

There are cases when programmers want to write a clean code but they cannot do that because they are being rushed. As a result they have to find quick and bad solutions.

From a business perspective, the implementation of suboptimal solutions may be seen as acceptable, however, from a technical standpoint, it can lead to complications in resolving future issues and may even make them impossible to fix.

VARIABILITY

Frequent change requests from the business team can create chaos in the code.

Such cases are often observed in startups where not all the requirements are predefined and the direction of the project may change rapidly. This can result in programmers having to change already implemented architecture or add new features to existing architecture, which can decrease code quality, making it harder to maintain and update in the future.

AVOIDING CONFLICTS

There are teams where all the programmers review the code of their teammates.

There are teams where experienced programmers review the code of teammates with less experience.

In both cases, the code reviewers may feel reluctant to raise issues or conflicts with the person who wrote the code.

Reviewers may overlook some obvious flaws, thinking that the author of the code may be upset or may harbor negative feelings towards them, if they bring up issues.

that's it...