Many of us have experienced the following: It’s code review time and Vince (name has been changed to protect identity) is presenting some very difficult logic he designed when the Team Lead notes that what he did is not going to work. Vince is floored and defends his reasoning trying to remain calm and focus on the issues he's addressing. The lead pushes back and defends why the code is not correct. Discussion escalates as people try to control their passions, and, in the end, no agreedment is reached and everyone is very frustrated.
The lead did everything they could to avoid attacking Vince personally and keep the discussion purely on the validity of the logic -- but to no avail. The lead had called Vince's baby ugly, thus launching Vince into defense mode. Logic was not going to prevail. Did the lead error in pointing out the flaw? Absolutely not, that is the purpose of a code review.
Code reviews are only going to be successful if all participants come to the table with a humble attitude -- a servant’s attitude. They need to be ready to listen and accept criticism. They need to distance themselves from their code (and ego) and recognize that their code does not define who they are.
This is much easier said than done. Developers take great pride in their work as they should. It takes a great deal of skill and intelligence to master today’s complex technical environments. Programmers pride themselves on their intellect, so it is difficult to separate themselves from the product of their intellect. It is going to hurt when that product is disparaged in any way even when done in the most constructive way.
A product owner, Scrum Master or technical lead can only do so much to build trust and establish an open environment where evreyone can feel safe to challenge one another and criticize each other's code. Ultimately though, each team member must also commit to being servant leaders in the sense of putting the team and the product ahead of their own pride.
They must learn to let go of their code when the rest of the team wants to do it a different way. And they must recognize when their pride has been pricked so they can stop and collect themselves before responding. Defendng one's position with humility and recognizing when it is time to submit to the team is key to the health of the group's environment and efficiency.
This is not to say there shouldn’t be passionate debates and advocating for what you believe in. In fact, this is what we want. The goal is to recognize when that debate is no longer productive, realize when it's time to humble oneself for the good of the team and the product, truly accept the result -- and let go.
