"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.
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 assume that nobody cares. I know, that sounds a bit harsh but as Neil Strauss suggests:
"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.
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.
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.
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?
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.
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 schedule a 15-30 minute meeting to discuss your large code review (I’ll create a separate blog post for this).
lengths and find that it’s unavoidable to submit a large code review,
then make sure you schedule a 15-30 minute meeting to discuss your large code review (I’ll create a separate blog post for this).
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”.
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”.
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 out of scope. Limiting your scope reduces the possibility of unnecessary back-and-forth comments for a change that falls outside your scope.
tested your code — or, better yet, ship your code review with unit
tests. Brownie points if you explicitly call out what is out of scope. Limiting your scope reduces the possibility of unnecessary back-and-forth comments for a change that falls outside your 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.”
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 you, the submitter of the code review, to make it as easy as possible for your reviews to leave comments (and approve).