Today we have a guest editorial from Hakim Ali.
This post was prompted by a code review session I attended recently. The code in question involved T-SQL stored procedures. There were five database developers in the room, looking over different components of an application we had divided up and coded amongst ourselves.
The raison d’être of a code review is to improve your code, to find things that the original coder may have missed and suggest ways of improving them. You do not go into a code review looking for an ego boost via validation that everything you did was right. You do not go into a code review fearing that others may find something wrong with your code. You definitely do not go into code review with a defensive and protective mindset, not open to critiques. And yet that is exactly what I encountered from one participant.
When this participant's code was being looked at, and one or two of us pointed out some things that he could have done in a more efficient manner, he started stonewalling and defending a position that we all (himself included, very likely) knew was wrong. Now I am not suggesting at all that you should not defend your position if you truly believe you are right. But when you know you are wrong and you do not accept it, what do you gain by the exercise? Why waste everybody's time, if you are not willing to be reviewed? Our friend made it clear that he was not going to be receptive to constructive criticism, and the atmosphere in the session almost immediately turned from one of camaraderie to sullen silences. I knew the rest of the session would be wasted time.
I look forward to being shown that I did something wrong, it helps me improve as a developer. A code review is a fantastic opportunity to look into other developers' minds, and to have peers suggest ways for you to improve your work. Why would anybody be resistant to that? I would be vastly disappointed if my code were being reviewed and nobody showed me ways of improving it.
The attitude above is largely from the perspective of the "reviewee". From the reviewer's point of view too, brutal honesty is the way to go. If you hold back as a reviewer because you do not want to hurt somebody's feelings, you have probably just done everybody in the room a disservice. You are a participant in the meeting for your technical abilities, to look over other developers' work and find any errors or inefficiencies. If you fail to do that, you have failed in your task to help develop the best product or service you can put out. I am not advocating that you should look to be mean and give other coders a hard time. Just be honest. Brutally honest.
Egos, feelings, false pride - these really should not come into the code review session. Check them at the door, and focus on one thing only: building the best software that can be built with the resources at hand. If you are lucky, somebody may just show you a way of doing something better, and help you find some coding Zen.
