What to do with bad code
Here is my humble advice about 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 reflections.
Usually, the first thing a person does when he encounters a bad code is looking for someone to blame. This immediately becomes a personal or tribal vendetta:
It is not right. Do not start with this. Before you find the poor creator of the code and bring down his anger on him, better understand the code itself.
Too often, the programmer is sure. People are already stubborn, but programmers are much more prone to this. They work with rigorous statements, so the origin of such confidence is understandable.
Immerse yourself in the code with curiosity and the desire to understand. Empathize with the person who wrote it. Imagine yourself in his place. He is not like you. Most likely, it is occupied by completely different concerns. Most likely, in his character there is no such layer of what is called perfectionism. Spaces around the parentheses or the naming of variables that are random at first glance might not get 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 splash self-proclaimed intellectual superiority.
Do you want to understand where these wild GOTOs come from, such branchy switches, stupid names, malformed formatting?
It is very easy to understand. Imagine that the code is yours and you will invent excuses for your own stupidity. Iron arguments will immediately come to mind: “I was in a hurry”, “I did not understand the API”, “I did not have the opportunity to fully understand the system” ... You will not have time to blink with an eye how you will have a whole battery of excuses, and only a few of them will be relevant to the case. You wrote the code badly. You are not above this.
')
Imagine yourself a biologist studying a new species that has been developing for millennia without supervision and the hand that guided it. Such a view requires questions. He requires an investigation. Of course, having the code, you can ask the author a question about his intentions, and, most likely, this is exactly what you will do.
It sounds crazy, but the way it is. You can go to the author and ask a question. Then I must warn you: it 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?
Yes, I'm afraid so. Now that you have found the problem, the need to transfer 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. Do not send a letter to the whole team. Do not shout from the roof. Do not write another blog post. The main mistake is the belief that:
And if you still have to write to everyone. If you have to shout from the roof. If you have to write a post that is so annoying to you, do not forget to use fables and hints, disguising the intentions of your ego. The name will still have to be given seriously to tempt the stubborn programmer to read it. Something like “What to do with bad code” will be just right.
Yes, sorry. You suck on many things. Yes, yes, you know something well, but otherwise it sucks. Do not blame others for not knowing as well as you (thinking of yourself). In the end, the truth may offend you. The fact that you are the same chick, like all other programmers ... and indeed all the others.
So, to the humiliation ...
Usually, the first thing a person does when he encounters a bad code is looking for someone to blame. This immediately becomes a personal or tribal vendetta:
"How can you be such an idiot?"
“Whose fault is that my brain exploded with all this incoherence and blasphemy?”
“Who insults <Company Name> !?”
It is not right. Do not start with this. Before you find the poor creator of the code and bring down his anger on him, better understand the code itself.
Understand the code
Too often, the programmer is sure. People are already stubborn, but programmers are much more prone to this. They work with rigorous statements, so the origin of such confidence is understandable.
Immerse yourself in the code with curiosity and the desire to understand. Empathize with the person who wrote it. Imagine yourself in his place. He is not like you. Most likely, it is occupied by completely different concerns. Most likely, in his character there is no such layer of what is called perfectionism. Spaces around the parentheses or the naming of variables that are random at first glance might not get 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 splash self-proclaimed intellectual superiority.
Really understand the code
Do you want to understand where these wild GOTOs come from, such branchy switches, stupid names, malformed formatting?
It is very easy to understand. Imagine that the code is yours and you will invent excuses for your own stupidity. Iron arguments will immediately come to mind: “I was in a hurry”, “I did not understand the API”, “I did not have the opportunity to fully understand the system” ... You will not have time to blink with an eye how you will have a whole battery of excuses, and only a few of them will be relevant to the case. You wrote the code badly. You are not above this.
')
Examine the original problem, investigate
Imagine yourself a biologist studying a new species that has been developing for millennia without supervision and the hand that guided it. Such a view requires questions. He requires an investigation. Of course, having the code, you can ask the author a question about his intentions, and, most likely, this is exactly what you will do.
It sounds crazy, but the way it is. You can go to the author and ask a question. Then I must warn you: it 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 transfer 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. Do not send a letter to the whole team. Do not shout from the roof. Do not write another blog post. The main mistake is the belief that:
- People still do not know about the pearl of wisdom that you want to share.
- People will sit and respectfully pay attention to the protective tone.
And if you still have to write to everyone. If you have to shout from the roof. If you have to write a post that is so annoying to you, do not forget to use fables and hints, disguising the intentions of your ego. The name will still have to be given seriously to tempt 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 on many things. Yes, yes, you know something well, but otherwise it sucks. Do not blame others for not knowing as well as you (thinking of yourself). In the end, the truth may offend you. The fact that you are the same chick, like all other programmers ... and indeed all the others.
So, to the humiliation ...
Source: https://habr.com/ru/post/174795/
All Articles