July 22, 2013 at 12:51Programmer Rule # 1: leave emotions at home!
- Transfer
As programmers, we are proud of our work. We show this pride in carrying out our tasks in the best way. We treat them with all meticulousness, including the names of variables and methods. We always select the necessary classes for a specific task, despite the fact that the user does not care if we used List> or Dictionary. 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 emotions get into the code because of this ? 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 defend themselves, if you just ask one question about their code. These are developers who enter into emotional debate if you suddenly suggest a way to improve their code. He or she begins to sulk when their way of solving the problem is called incorrect, inappropriate, and most likely they will remember it in the future.
The fact is that we all were like that before. Especially when we were “junior” developers who had little understanding of any technology, we wrote code that seemed ideal to us, 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 saddened by the existence of a built-in class that did what we spent half the week doing.
But, when we were gaining experience, when there was a thirst in us to learn more about the technologies that we used, we began to separate ourselves from our work. Many have learned to find a better way to solve the problem than the one they implemented. Many of us are even carried away by this. 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 have embarked on this path. Some developers have remained on the step of "rejecting criticism."
What causes this behavior? I believe that this is not bitterness, not infantilism, not exaltation of oneself over others. My opinion is that 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 the problem means that I am a fool. I think that developers who protect their code to the last are secretly afraid that their value in the eyes of others will decrease when the code written by them is accused of non-optimality. Regardless of the cause.
There are several solutions to this problem. The first is a simple conversation with him or her. Let them know that they are tootied to their work and this reduces the quality of the whole product. For many people, this will be enough. Nobody wants to be responsible for a bad product, and if you show it in the right light, then the developer begins to work with the whole team, and not against it.
But what if it didn’t work? Well, you do not have such pleasant solutions. If that programmer doesn't give up, then the best way is to enlist the support of the rest of the team. If he is not a team leader and not a manager, then his bad code (and attitude to work) will not resist the rest of the team.
The next step is to propose improvements directly to the manager or team lead. Unfortunately, you may get the feeling that you “stabbed” the rest of the team, so you should bring along another competent developer who could confirm that your method is really better, or adjust it together with you. Offer your decision to the manager, let other developers defend their positions and let the manager make a decision. Now everything is in his hands and you cannot influence his decision. If he chooses a different path, then at least you tried.
As developers, we should be less emotionally attached to our code. Remember this when you again think of a dispute against this definitely better solution than yours.
But what happens when a developer is too proud of what he or she wrote?
What if emotions get into the code because of this ? 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 defend themselves, if you just ask one question about their code. These are developers who enter into emotional debate if you suddenly suggest a way to improve their code. He or she begins to sulk when their way of solving the problem is called incorrect, inappropriate, and most likely they will remember it in the future.
The fact is that we all were like that before. Especially when we were “junior” developers who had little understanding of any technology, we wrote code that seemed ideal to us, 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 saddened by the existence of a built-in class that did what we spent half the week doing.
But, when we were gaining experience, when there was a thirst in us to learn more about the technologies that we used, we began to separate ourselves from our work. Many have learned to find a better way to solve the problem than the one they implemented. Many of us are even carried away by this. 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 have embarked on this path. Some developers have remained on the step of "rejecting criticism."
What causes this behavior? I believe that this is not bitterness, not infantilism, not exaltation of oneself over others. My opinion is that 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 the problem means that I am a fool. I think that developers who protect their code to the last are secretly afraid that their value in the eyes of others will decrease when the code written by them is accused of non-optimality. Regardless of the cause.
There are several solutions to this problem. The first is a simple conversation with him or her. Let them know that they are tootied to their work and this reduces the quality of the whole product. For many people, this will be enough. Nobody wants to be responsible for a bad product, and if you show it in the right light, then the developer begins to work with the whole team, and not against it.
But what if it didn’t work? Well, you do not have such pleasant solutions. If that programmer doesn't give up, then the best way is to enlist the support of the rest of the team. If he is not a team leader and not a manager, then his bad code (and attitude to work) will not resist the rest of the team.
The next step is to propose improvements directly to the manager or team lead. Unfortunately, you may get the feeling that you “stabbed” the rest of the team, so you should bring along another competent developer who could confirm that your method is really better, or adjust it together with you. Offer your decision to the manager, let other developers defend their positions and let the manager make a decision. Now everything is in his hands and you cannot influence his decision. If he chooses a different path, then at least you tried.
As developers, we should be less emotionally attached to our code. Remember this when you again think of a dispute against this definitely better solution than yours.