Programmer Rule # 1: Leave your emotions at home!
As programmers, we are proud of our work. We show this pride by performing our tasks in the best way possible. We treat them with all the meticulousness, right up to the names of variables and methods. We always choose the necessary classes for a specific task, despite the fact that the user doesn’t care if we used List <KeyValuePair <Guid, string >> or Dictionary <Guid, string>. We are nervously trying to bring everything to perfect condition. Many may even think that we have OCD .
But what happens when a developer is too proud of what he or she wrote?
What if, because of this, emotions get into the code? What can happen if a programmer cannot part not only with his or her code, but also with the methods of conducting work, making decisions and his behavior as a developer?
')
We all dealt with such people. They always stand on the defensive if you only ask one question about their code. These are developers who engage in emotional debates if you suddenly suggest a way to improve their code. He or she begins to sulk when their way of solving a problem is called wrong, unsuitable, and most likely they will recall this in the future.
The fact is that we were all like that before. Especially when we were “junior” developers with little understanding of any technologies, we wrote code that seemed to us ideal, although it was often not optimal for a specific task. We all recognize this feeling inside, when a more experienced developer showed us a better, more correct way to solve this problem. We were depressed by the existence of a built-in class that did what we spent half a week on.
But when we gained experience, when we had a thirst to learn more about the technologies we used, we began to separate ourselves from our work. Many learned to find a better way to solve the problem than the one they implemented. Many of us even got carried away with it. The more we learned about a particular technology, the more we learned things that really simplified our lives, and we liked it. Unfortunately, not all programmers embarked on this path. Some developers remained on the “non-criticism” step.
What causes this behavior? I believe that this is not bitterness, not infantilism, not elevating oneself above others. My opinion - this is due to self-doubt. When I was still green, I always thought that any change in my code or the choice of another way to solve a problem meant that I was a fool. I think, developers who protect their code to the last, are secretly afraid that their importance in the eyes of others will go down when the code written by them is accused of non-optimality. Regardless of the cause.
There are several ways to solve this problem. The first is a simple conversation with him or her. Let them know that they are too attached to their work and this reduces the quality of the whole product. For many people, this will be enough. No one wants to be responsible for a bad product and, if you show it in the right light, the developer starts working with the whole team, and not against it.
What if it didn't work? Well, you do not have such pleasant solutions. If that programmer does not give up, then the best way is to enlist the support of the rest of the team. If he is not a team lead and not a manager, then his bad code (and attitude to work) will not stand in front of the rest of the team.
The next step is to suggest improvements directly to the manager or team lead. Unfortunately, you may have the feeling that you “hit in the back” with the rest of the team, so you should take with you another competent developer who could confirm that your way is really better, or correct it with you. Suggest your decision to the manager, let other developers defend their positions and let the manager decide. Now everything is in his hands and you cannot influence his decision. If he chooses another way, then at least you tried.
As developers, we should be less emotionally attached to our code. Remember this when you reconsider arguing against this definitely better solution than yours.
But what happens when a developer is too proud of what he or she wrote?
What if, because of this, emotions get into the code? What can happen if a programmer cannot part not only with his or her code, but also with the methods of conducting work, making decisions and his behavior as a developer?
')
We all dealt with such people. They always stand on the defensive if you only ask one question about their code. These are developers who engage in emotional debates if you suddenly suggest a way to improve their code. He or she begins to sulk when their way of solving a problem is called wrong, unsuitable, and most likely they will recall this in the future.
The fact is that we were all like that before. Especially when we were “junior” developers with little understanding of any technologies, we wrote code that seemed to us ideal, although it was often not optimal for a specific task. We all recognize this feeling inside, when a more experienced developer showed us a better, more correct way to solve this problem. We were depressed by the existence of a built-in class that did what we spent half a week on.
But when we gained experience, when we had a thirst to learn more about the technologies we used, we began to separate ourselves from our work. Many learned to find a better way to solve the problem than the one they implemented. Many of us even got carried away with it. The more we learned about a particular technology, the more we learned things that really simplified our lives, and we liked it. Unfortunately, not all programmers embarked on this path. Some developers remained on the “non-criticism” step.
What causes this behavior? I believe that this is not bitterness, not infantilism, not elevating oneself above others. My opinion - this is due to self-doubt. When I was still green, I always thought that any change in my code or the choice of another way to solve a problem meant that I was a fool. I think, developers who protect their code to the last, are secretly afraid that their importance in the eyes of others will go down when the code written by them is accused of non-optimality. Regardless of the cause.
There are several ways to solve this problem. The first is a simple conversation with him or her. Let them know that they are too attached to their work and this reduces the quality of the whole product. For many people, this will be enough. No one wants to be responsible for a bad product and, if you show it in the right light, the developer starts working with the whole team, and not against it.
What if it didn't work? Well, you do not have such pleasant solutions. If that programmer does not give up, then the best way is to enlist the support of the rest of the team. If he is not a team lead and not a manager, then his bad code (and attitude to work) will not stand in front of the rest of the team.
The next step is to suggest improvements directly to the manager or team lead. Unfortunately, you may have the feeling that you “hit in the back” with the rest of the team, so you should take with you another competent developer who could confirm that your way is really better, or correct it with you. Suggest your decision to the manager, let other developers defend their positions and let the manager decide. Now everything is in his hands and you cannot influence his decision. If he chooses another way, then at least you tried.
As developers, we should be less emotionally attached to our code. Remember this when you reconsider arguing against this definitely better solution than yours.
Source: https://habr.com/ru/post/187416/
All Articles