What to do with bad code

Here is my humble advice on how, in my opinion, people should deal with bad code. This advice has nothing to do with technology; strictly speaking, this is not even advice, but simply my recent thoughts.

Usually, the first thing a person does when he encounters a bad code is to look for the culprit. It immediately becomes a personal or tribal vendetta:

“How can one be such an idiot?”
“Who is to blame for the fact that my brain exploded from all this incoherence and blasphemy?”
“Who insults <Company Name> !?”

It is not right. No need to start with this. Before you find the poor creator of the code and bring down your anger at him, better understand the code itself.

Understand the code

Too often, the programmer is sure. People are stubborn anyway, but programmers are much more prone to this. They work with rigorous statements, so the origin of such confidence is clear.
Immerse yourself in the code with curiosity and a desire to figure it out. Empathize with the person who wrote it. Imagine yourself in his place. He is not like you. Most likely, he is occupied with completely different concerns. Most likely, in his character there is no such layer of what is called perfectionism. Spaces around brackets or randomly naming variables at first glance might not be in the focus of his attention. Maybe he has his own life.
Without empathy, there will be no understanding of the code itself, nor of where it came from. You will only verbally spray self-proclaimed intellectual superiority.

Really understand the code

Want to understand where these rampant GOTOs come from, such branchy switches, dumb names, ugly formatting?
To understand is very simple. Imagine that the code is yours and you will invent excuses for your own stupidity. The iron arguments immediately come to my mind: “I was rushed”, “I did not understand the API”, “I did not have the opportunity to fully understand the system” ... You won’t have time to blink, as you will have a whole battery of excuses, and only a few of them will to be relevant. You wrote the code poorly. You are not above that.

Examine the original problem, investigate

Imagine yourself as a biologist studying a new species that has developed for thousands of years without supervision and with the hand that guides it. This view requires questions. He needs an investigation. Of course, having a code, you can ask the author a question about his intentions, and most likely that is what you will do.
It sounds crazy, but it is. You can go to the author and ask a question. Here I must warn you: this may force you to drink from the cup of humiliation.
But what if there is no good reason? What if it's all from laziness, ignorance, or even malice?

Learn

Yes, I'm afraid so. Now that you have found the problem, the need to convey wisdom falls on your shoulders so that no one will ever fall to such a lousy code.

Do not let your ego lead you on occasion. Do not send a letter to the whole team. Do not scream from the roof. Do not write another blog post. The main mistake is the belief that:

• People do not yet know about the pearl of wisdom that you want to share
• People will sit and respectfully listen to the patronizing tone.

And if you still have to write to everyone. If you have to scream from the roof. If you have to write a post about something that annoys you so be sure to use fables and hints to mask the intentions of your ego. Still, the name will have to be given seriously in order to seduce the stubborn programmer to read it. Something like "What to do with bad code" will be just right.

Seriously, you suck too

Yes, sorry. You suck for many things. Yes, yes, you know something well, but in all other respects it sucks. Do not blame others for not understanding them as well as you (think of yourself). In the end, the truth can offend you. That you are the same chick as all other programmers ... and indeed everyone else.

So, to the cup of humiliation ...