How to Reduce Pain in Code Reviews

Why is code review so painful?

Code reviews are stressful, especially as a new developer. And yet, it's such an integral part of everyday life as a software engineer. I posted about this a couple of months ago:

From the discussion that ensued, here are some additional tips for reviewing code most effectively:

• Use "we" instead of "you" whenever possible, but stay clear of sounding like an obsequious waiter asking, "...and how are we enjoying the duck?"
• Before opening an issue, ask: "does this matter?" Style is essential to a certain point, but the crucial thing is, will someone else understand this code later on.
• Code review is highly dependent on your company. For example, at LinkedIn, we trust that the submitter likely found the right solution, and reviews are focused mostly on maintainability and company-wide code standards. In other places, code review could have a much higher bias towards validating functionality.

Where to go from here?

Before submitting a code review, make sure to review it yourself first. Self-review is an easy way to reduce the number of issues present within your code and to sharpen your review skills!

Should you get less than compassionate code reviews, do your best not to take it personally. Not everyone has read about how best to review, and are unaware of how negatively they affect others when they bash a submission. Reply with warmth when you disagree. Approach them directly about raising issues more compassionately or mention it to their manager: this is an easy way for them to grow, and most software engineers want all feedback they can get to improve. If all of this fails, keep your head up and push through. Act as an example they can learn from, and you will outshine these peers who spread negativity.

Code review is just one aspect of software engineering, but it's a core piece. Expect another deep dive into code reviews in the next article, after which I'll broaden to other software engineering topics.