Tired of Reviewing Code? Here's How to Make It Easier
Three easy steps to make code reviews the easiest task on the day.
Hello friend! 👋
Basma here. Thank you for reading An Engineer's Echo, your weekly publication of stories to equip you with the soft and hard skills to fast-track your growth in software engineering.
Reading Time: 4 mins.
Last week, we talked about why code reviews are important for your growth in the software engineering world.
This week, let’s tackle the practical side: How to make code reviews less of a headache.
Let’s be real, most of us aren’t exactly jumping for joy when it comes to code reviews. Been there, done that! I remember times in my career when I’d rather do anything else than review code. I’d procrastinate, getting stuck in a loop of starting, stopping, and going back and forth, which doesn’t exactly scream "team player."
We do code reviews almost every day, so you’d think they’d become routine. But nope, each pull request brings its own unique challenges. To review effectively, you’ve got to be sharp, pay attention, and keep the vibes positive. So, how do we turn this heavyweight task into a breeze?
Here’s what we’ll cover today:
Slot it in: Pick different time slots in your day for reviews.
One shot, one timer: Knock it out in one go, and set a time limit.
Know when to go live: Recognize when to ask for a live code review.
1. Slot it in: Pick different time slots in your day for reviews.
One of the reasons why we hate code reviews is that they can be distracting.
Switching context is bad because you can take up to 10-15 minutes to get back to what you were working on.
So, what I found an effective solution to this problem, is:
Put different slots during the day to review code, every slot is around 15 minutes or so.
I am deliberate for them to be multiple small slots rather than one big slot. As, you can have multiple reviews coming during the day that need your attention.
Now, you might be wondering, what about urgent reviews to unblock people…
Well, if it’s an urgent review then sure unblock the author, and review the code, but always assign a specific time to it.
Read on there’s more advice on how to give it concentrate focus.
2. One shot, one timer: Knock it out in one go, and set a time limit.
Our brains work better when tasks are short, like 10 minutes or less. Plus, having a timeframe in mind helps keep us on track.
Usually, if PRs are small (as they should be), code reviews shouldn’t take more than 10 minutes if you’re fully focused.
I used to be all over the place when I reviewed code. Chat app, email, phone—sound familiar? All that distraction? Yep, been there. But why? Because I was avoiding the task.
When I dug into why I was dodging, turns out there were a few reasons:
Unfamiliar code: If the change is tough to grasp.
Big PRs: Too much code to sift through.
Lack of context: Clueless about what's going on.
So, I started tackling each issue separately. And bam! Code reviews got faster.
Here’s what works:
Divide and conquer: Break the change into smaller bits.
Test the waters: Start with the tests—they’re like breadcrumbs in the code.
Hide what's done: Keep track of what’s reviewed by hiding files.
Ask questions: If something’s fuzzy, ping the author for clarity.
If the PR’s a monster, ask nicely if it can be split into smaller ones. If not, refer back to the first point.
And most importantly, set a time limit. Don’t drag it out forever. If it’s over 15 minutes, your focus will wane. If you’re stuck, hang tight, next point's got you covered.
3. Know when to ask for a live review.
As mentioned, setting a time limit for reviews is crucial.
Otherwise, it becomes a daunting, never-ending task, and the procrastination cycle kicks in. Trust me, I’ve been there.
Here's how to spot when a review is dragging:
Lots of back and forth in the comments.
Spending over 20 minutes on a single review session.
Changes you requested aren't addressed properly (a sign of miscommunication).
If any of these happen, it's time for a live pairing review. This indicates a clear communication gap.
To my surprise, a quick 10-minute live pairing session can work wonders. PRs that were stuck in endless back-and-forth get sorted in no time. Give it a shot and thank me later!
Of course, not every PR needs a live review—otherwise, we'd spend all day reviewing! You need to struck a balance here.
Conclusion and Key Takeaways
In conclusion, making code reviews a breeze is all about smart time management and effective communication.
Remember, spotting signs of a dragging review and addressing them promptly can save both time and sanity. So, next time you dive into a code review, keep these key takeaways in mind:
Schedule dedicated time slots for reviews to maintain focus.
Set time limits to prevent reviews from becoming overwhelming.
Recognize when a review is dragging and pivot to live pairing if needed.
Effective communication is key to closing the gap and speeding up the process.
With these strategies in your toolkit, you'll breeze through code reviews with confidence and efficiency.
I’d love to know if this advice was helpful when you tried it, and whether you’re already doing some or all of them. Let me know in the comments or by replying to the email! 😊
Thank you for reading! I hope you enjoyed it, let me know by hitting the like button ❤️ to help others find it on Substack, and share it to spread the love!
Great articles you don’t want to miss!
Keep Weekly Highlights of your work to succeed — by
The Common Types of Technical Tests — by
Beyond Guesswork: The Art and Science of Project Estimation — by
Thank you! Speak next week 😊
— Basma