So, you want my opinion?
I’ve been code reviewing applications for several years now. For some reason, I’ve found myself to be quite capable of picking up a piece of code and understanding the goal trying to be achieved. This ability lends itself well to code reviewing others’ code.
Typically, I end up assigned onto code reviews because I’m a very opinionated and vocal individual. I like to think that I’m thorough, as well. These traits combine lend themselves well when combined with knowledge in a certain skillset.
Even as a new employee, I quickly filled the role of reviewer (and it takes up a good chunk of my time!). There was some downtime between tasks and I picked up a few pull requests and added my opinion. From there, I found myself being added to more reviews that were outside the realm of my responsibility.
My style & personality
The above is all well and good…for somebody who has more empathy and social awareness than what I have. If you’re familiar with emergenetics, my profile has 2% social in it, which means when I approach a problem or conversation, I am not very likely to take others’ feelings or reactions into consideration when communicating.
This leads to quite a few problems in the workplace…as one would expect. I will add my opinion to a code review and not really care how many comments there are, how I’m wording a particular comment, or how any of these will be taken by the reader.
Realizations and lessons learned
Now that I’m a contractor, I’ve realized that my style of code reviews has a broader impact than just the code base. Before, I was able to talk to the person who I was reviewing code for in person. I could express what I was saying with clear tone of voice and clarify immediately.
However, I don’t have that luxury as a remote contractor. The individuals I’m critiquing imply a tone while reading a comment. This can lead to personality conflicts. In addition, any personality conflicts between myself and my coworkers reflects on the company I directly work for.
This is something that ought to be on the forefront of my mind when writing these sorts of reviews.
Steps to reduce friction
I’ve read a few articles on how to reduce the amount of friction between reviewer and reviewee. Most of them can be generalized into good social awareness. But, here’s what I’m going to be working on doing to help interpersonal relations between myself and the people who’s code I’m reviewing:
- Ask questions as opposed to making statements (i.e. Could we approach the problem in this way?)
- Explain the thought process behind a given comment
- Give the pros and cons of my solution, not just the pros
- Uncertain about what’s being done? Ask for clarification
- Ask for feedback on the review process
- Offer to hop on a call and discuss comments, especially if the number of comments on a code review is higher than average
Wrapping this up and tying it to the title of this blog post…I’ve found that code reviewing is definitely an art form. You have to find the right balance between being a critical hard-ass and empathy towards the author. Too little crituque can lead to problems down the road, with poor practices flourishing. However, what good is a review if people think of you negatively as a result of being overly critical of something they put so much time into?
I’ll be the first to admit I lean more towards the overly-critical side. It’s a problem that has put strain on relationships with coworkers before, but it also has lead to me being able to spread a lot of what I’ve learned over the years. I’ve found that code reviews are the best place to highlight tried and tested approaches to problems. In addition, I’ve also learned a significant amount from others while reviewing their code. It’s not a one way street, and it is beneficial to everyone involved.
There’s a ton of value in open and honest communication. I will continue to work on ensuring my coworkers understand that I’m critical because I want to help, but I also need to realize how that is being perceived. Here’s to continuing to better my art.