Code Review is a normal practice and it’s in almost every Software Industry’s DNA. We’ve been conditioned with the idea that it’s always good to have a second set of eyes look at your work prior to production movement.
Writing and reviewing code is no exception. It’s pretty easy to forget minor things like proper variable initializing, disposing and freeing up resources at the end of execution and many more things. Therefore, having someone review your work only makes sense. In fact, it makes so much sense that software departments formalized the process, calling it “code review.”
Sometimes Code Review can create conflicts between teammates!
If your code has code reviews, then it might happen, you may land in a situation where office politics land. Sometimes for small reasons discussions between you and reviewer may become toxic. If your code is getting reviewed remotely, then that’s a different picture. You will first initiate the same officially in Visual Studio, then it will go to the reviewer. He/She will go through the code and put comments against the same. If there is any change suggested, you would be changing the same and getting reviewed again, and upon approval; you can commit the code. So, this is the ideal scenario and flow of code review. But, many a times it happens if reviewer sits next to you, then in that case you just walk to him and show the code to him. This will significantly reduce the code-review time and process can be completed very fast.
But, if office politics is surfacing and you are not very comfortable with reviewer because of any crap reason, he will normally give reason; “I will have a look and let you know“. This can be +ve or -ve as well depending on your attitude in office or depending on your relationship with your lead.
searching for bug
I would suggest let code review happen with reviewer’s pace. With this approach reviewer will get ample time to have a look at code and discover if there is any bug left in the code. But, sometimes this code review may become to belittle developer by showcasing some of the minor mistakes and making it feel major. Again, this scenario depends on your relationship with Reviewer or if Reviewer is insecure from you. Let’s look at some types of personalities you may have to deal with in the office and ways you can avoid office politics anti-patterns around code review.
“Big Shot is here”
The “Big Shot is here” is mostly the least intricate political situation, though it has the potential to be among the most counterproductive. In this situation, there’s a pushy personality that mandates other team members to code according to his/her coding style.Usually this personality tendency is to make sure that I Run the Show. Many a time, this may not be the case; he/she may ask you to stick to standard and tested design pattern.
You can always recognize the political situation and the crux of the problems which is generally caused by words and attitudes of other team members. The best case could be Big Shot is really Big Shot, and his/her intention is not to belittle you rather to teach you good programming practice. And there is nothing wrong in that. The worst could be he/she is technically incompetent and he is here just because of seniority and pushing unnecessary rules just to justify his seniority. I hope and wish, you guys won’t have to face worst case scenario. Even in this case, you can rephrase your comments diplomatically. Again, it entirely depend on you, how you tackle the situation.
“Stop being Impulsive”
If the group with a big shot is monopoly, you can still stay cool guy by agreeing on majority of points rather disagreeing and showing your disagreement instantly. Generally, in old organizations or in typical service industry, position is not ruled by a single dictator but by a cartel of established, senior people. Therefore, by agreeing on a lot of things, you can cut majority infrequent disagreements @floor. There is one catch in being cool and casual as well. Let us suppose, you hired freshly, which means, you are bringing your fresh viewpoints to the industry. And without realizing the actual fact, you simple started rejecting your seniors’ view, then in that case, they will assume that HIRING you is a BIG-MISTAKE, and they will start looking for mistakes in you to fire you in sometime. If you still feel, that your views are correct and not getting addressed, then prove it with POC(Proof of Concept) in software terms.
Lastly, Ensure that reviews are two-way-process. And it should be win-win for both developers and reviewer as well. Few Key-points:-
Always focus on the code and not the person who wrote the code.
Make the reviews small, frequent, and informal. This way even reviewer feel happy and stay stress free. Therefore, follow agility as long as possible.
Rephrase things as questions and suggestions rather than orders and blame. Ask others as well to follow the same pattern. This way you are making sure, you are not biased.
Try to make framework which will inspect basic coding guidelines. This way, it will cut-short time in future-code-reviews.
But, in my experience, the single most important thing you can do to cut down on politics is by accepting feedback from others by saying how can we improve further.
Thanks,
Rahul Sahay
Happy Coding
