"Why is nobody reviewing my code?" I often witness new engineers (or even seasoned engineers new to the company) submit code reviews that end up sitting idle, gaining zero traction. Often, these code reviews get published but comments never flow in, leaving the developer left scratching their head, wondering why nobody seems to be taking a look. To help avoid this situation, check out the 3 tips below for more effective code reviews. 3 tips for more effective code reviews Try out the three tips for more effective code reviews. In short, you should: Assume nobody cares Strive for bite sized changes Add a descriptive change summary 1. Assume nobody cares After you hit the publish button, don’t expect other developers to flock to your code review. In fact, it’s safe to I know, that sounds a bit harsh but as Neil Strauss suggests: assume that nobody cares. "Your challenge is to assume — to count on — the completely apathy of the reader. And from there, make them interested.” At some point in our careers, we all fall into this trap. We send out a review, one that lacks a clear description (see section below “Add a descriptive summary”) and then the code review would sometimes sits there, patiently waiting for someone to sprinkle comments. Sometimes, those comments never come. Okay, it’s not that people don’t necessary care. It has more to do with the fact people are busy, with their own tasks and deliverable. They too are writing code that they are trying to ship. So your code review essentially pulls them away from delivering their own work. So, make it as easy as possible for them to review. One way to do gain their attention is simply by giving them a heads up. Before publishing your code review, send them an instant message or e-mail, giving them a heads up. Or if you are having a meeting with that person, tell them that you plan on sending out a code review and ask them if they can take a look at the code review. This puts your code review on their radars. And if you don’t see traction in an appropriate (which varies, depending on change and criticality), then follow up with them. 2. Strive for bite sized code reviews Anything change beyond than 100-200 lines of code requires a significant amount of mental energy (unless the change itself is a trivial updates to comments or formatting). So how can you make it easier for your reviewer? Aim for small, bite sized code reviews. In my experience, a good rule of them is submit less than 100 lines of code. What if there’s no way your change can squeeze into double digits? Then consider breaking down the single code review into multiple, smaller sized code reviews and once all those independent code reviews are approved, submit a single code review that merges all those changes in atomically. And if you still cannot break down a large code review into these lengths and find that it’s unavoidable to submit a large code review, then make sure you (I’ll create a separate blog post for this). schedule a 15-30 minute meeting to discuss your large code review 3. Add a descriptive change summary I’m not suggesting you write a miniature novel when adding a description to your code review. But you’ll definitely need to write something with more substance than a one-liner: “Adds new module”. Rob Pike put’s it succinctly and his criteria for a good description includes “What, why, and background”. Good example of descriptive change summary from the IntelDPDK code base In addition to adding this criteria, be sure to describe how you tested your code — or, better yet, ship your code review with unit tests. Brownie points if you explicitly call out what is . Limiting your scope reduces the possibility of unnecessary back-and-forth comments for a change that falls outside your scope. out of scope Finally, if you want some stricter guidelines on how to write a good commit message, you might want to check out Kabir Nazir’s blog post on “How to write good commit messages.” Summary If you are having trouble with getting traction on your code reviews, try the above tips. Remember, it’s on , the submitter of the code review, to make it as easy as possible for your reviews to leave comments (and approve). you

Code Reviews: Tips On Getting More Feedback

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Canaries to the Rescue: Catching Service Issues Before the End User

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

10 Expert Tips for Improving Code Reviews: A Guide for Developers

10 Coding Hacks to Remember in 2023

Canaries to the Rescue: Catching Service Issues Before the End User

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

10 Expert Tips for Improving Code Reviews: A Guide for Developers

10 Coding Hacks to Remember in 2023

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps