It is not natural to let others point out that mistakes at work need to be learned. We are proud of our work and never agree to mistakes. We do not know how many mistakes we have made, nor do we want others to discover these mistakes. If you are working on building a successful peer review, these natural conflicts must be overcome.
Peer review is a social activity similar to technical training. In an organization, the review process should be gradually instilled to understand the organizational culture and the values held by Members. Managers should believe that the time spent in review is a type of cast, and then arrange review for the team. You need to understand why some people are unwilling to give their work to their colleagues for a detailed review, and Complained constantly. You also need to explain peer review processes, expected behaviors, and help to individuals and teams to the team and manager.
Scratching your back
Busy colleagues sometimes don't want to spend time seeing their work. You may think the other party is a slide. Is he not confident? Does he want you to think for him? Colleagues who resist review may laugh like this and say, "No programmer who needs to review the code can afford to receive the salary !"
In a healthy software engineering culture, the team members attract their colleagues to work together to improve the quality and productivity of their work. In this equivalent interaction process, the time they spend in review others' work will be rewarded in others' review their work. All the great programmers I know will take the initiative to Select reviewers. The majority of review views will make them better, especially those that exceed their personal abilities.
<The psychology of computer programming> published in 1971 (record 1998), author Gerald weberger introduced "no-me programming" and explained the fact: people are bound to their own work. Discovering a defect made by others will make you feel that this is an injury to your self-esteem as a programmer, or even hurt your self-esteem as a person. To protect yourself, you do not want to know your mistakes, or even make excuses for possible bugs.
Such strong self-protection is a typical obstacle for effective peer review, which leads to a single fight attitude in team projects and must also produce low-quality products. No-me programming advocates the author's retreat and others will point out where his work needs to be improved. In this mode, programmers fully understand how to make their work easier for others to understand. On the contrary, some programmers are willing to write obscure and intelligent code that they can understand. This concept will make everyone who understands the code suffer. Managers who focus on non-me programming will contribute to a collaborative atmosphere in the team, share achievements, and share knowledge and skills openly in the team.
Note that this term is "no-me programming", rather than "no-Me programmers ". Everyone has the right to protect themselves. developers need to be healthy and self-conscious enough to trust and guard their work. Otherwise, they will reject better suggestions. The Feasibility cannot be determined)
Software Industry experts are proud of their creative work, even though they realize that people always make mistakes and get a lot from external perspectives. A non-mine review will sympathize with his colleagues. Unless they have special reasons, they will switch roles for a day and take review seriously.
Review and team culture
When independent programmers can often get from peer review, a normal review process can only succeed in a culture that emphasizes quality. Programmers who regard review as a development activity will help individuals and teams succeed. They understand that review is by no means intended to discover poor developers, nor to find a scapegoat for quality problems.
Review may also lead to two bad attitudes. Some people start to become lazy, because others will help them find problems. This is just like a programmer expecting testers to find their mistakes. As a matter of fact, the author is ultimately responsible for his work. Review is only an auxiliary means to help the author create high-quality results. Sometimes, when I read my draft, I often hear a small voice that tells me something wrong or the syntax is inappropriate. I sometimes tell myself: "I should give it to reviewers to see what they think ". The problem is that those readers do not always like the poor chapters. Now, when I hear this voice, I will take the initiative to correct it, instead of wasting time on reviewers.
Another thing that needs to be avoided is the temptation to pursue perfection and strive to make the work perfect before sending a review. This is a self-protection strategy: You don't have to be embarrassed by mistakes that others don't see. I once brought an engineer. She never gave a review before the work was completed, or before she thought it was good enough. She basically did everything: complete implementation, testing, standard-format code, and documentation. She regards review as a type of receiving authentication, rather than a quality improvement activity in the actual development process.
