My thoughts on Code Reviews

I'd like to start by thanking Scott Hanselman and Michaela Greiler for delivering a very insightful podcast on Enjoyable Code Reviews. It's a topic we encounter often but rarely talk about it. So, as soon as I saw the podcast show up in my app, I jumped on it to give it a listen.

I thought I'd also share my experience, and have the conversation going. I'd have to agree with the Host, and Guest - there's not a whole lot of positivity around Code Reviews. I believe the biggest reason behind such an unpleasant experience is - the expectations are not clearly laid out. If the Reviewer has shared a checklist of their expectations then it'd not only make the whole process go faster but also enjoyable. Sometimes, I have also seen engineers get too attached to their code, and they do not seem to be super welcoming to the code review feedback.

When I'm reviewing code - I take it as an opportunity to connect with my engineers in the playground they enjoy the most. It's a time I look forward the most to have a conversation with them right there in their playfield. You might have questions about why something was done in a certain way. Well, this is the time you can tap into some of that reasoning. 

Step One - Socialize. I can't really stress this enough as it's such an underserved area. Socializing builds connections and relationships - the thriving force behind most of the successful endeavors. It also takes away the awkwardness or hesitation from reviews and will make both the parties more recipient to each other's thoughts. If you believe in a certain programming paradigm like Clean or SOLID Code then talk about it. Your team would get to know your approach, and start following along.

Step Two - Have a checklist. List down what you like to see, and whatnot. It's a good way to kill any surprises to come out from your review.

Step Three - Make peer code reviews mandatory as the first step of the review process. As a reviewer, it'll save a lot of your time, and give the third eye advantage to your engineer.

Step Four - Bring in Automation. Would not it be efficient if some or all of the feedback from your checklist can be delivered in real-time while your engineers are writing code? Some of the tools to utilize in this space are - SonarQube VS Plugin, Resharper, Amazon CodeGuru, and Sourced.Tech. Or, you could try to write your own analyzers.

It's ok to dream about bigger architectures, designs, or pain points and have them show up in reviews but please do not scope creep. Instead, add those thoughts in the backlog to be addressed in the future.

Have fun Code Reviews.

Appendix:

My WIP Checklist for a .Net Core Web Api -

Add comment