Code Reviews: Managing review workload
How to create a personal workflow to keep up with code review requests, plus some bonus talk about prepping for Gophercon EU!
I'm writing this from Berlin as I get ready for Gophercon EU to kick off tomorrow! The long flight over gave me the perfect opportunity to do a major revamp of my website—and I managed to do it WITHOUT creating a new repository and starting from scratch. I definitely deserve a medal for that one!
I wanted a single place to showcase everything I do online, so I added a content filter to highlight all my recent work. I'm really excited about how it turned out.
The last six weeks have been a whirlwind of travel and Gophercon prep, but now that things are settling down, I'm feeling that creative energy returning. I've got some exciting projects in the works for the next few weeks that I can't wait to share!
Highlights
Things I've been doing on the internet
- Article: How the GitHub billing team uses the coding agent in GitHub Copilot to continuously burn down technical debt
- I wrote this for the GitHub blog and it is one of my favorite things I've done recently! I am becoming pretty passionate about the affect of AI Agents on modernizing legacy systems!
- Podcast: Overcommitted Ep. 11 | Thinking in Systems - Book club recap
- This was SUCH a fun episode. I actually listened to the whole thing myself on the plane and enjoyed hearing it all back. This was such a good book and I learned so much sharing the book club with Bethany and Erika!
- Illustration:
- Everyone knows writing a more complex architecture diagram is the key to success! By the way, you can now check out all of my illustrations on my website!
Things I've enjoyed on the internet this week
If you've got something you want me to read and feature in this newsletter, send it to me at brittany@balancedengineer.com!
- Book: 100 Go Mistakes
- I have been hyper-focusing on my talk got Gophercon EU and ended up reading quite a bit of this book as part of it!
Onto the content!
You know that feeling when you open your slack notifications and see 23 unread notifications? Your heart races as you wonder: Are these all urgent review requests? Did I miss something critical? Which ones actually need my attention right now?
If this sounds familiar, you're not alone. Managing pull request review requests is one of those skills that nobody teaches you, but it becomes increasingly important as you grow in your career. The ability to stay on top of code reviews isn't just about being a good teammate. It's one of the most direct ways to unblock your colleagues and measure your collaborative impact.
June Theme: Code Reviews
This month, we're exploring the world of code reviews—from writing better pull requests to giving constructive feedback. Code reviews are where technical excellence meets human collaboration, and mastering them can significantly impact both your code quality and team relationships.
Why Managing Review Requests Matters
As you advance in your engineering career, code reviews become a larger part of your daily work. Senior engineers often spend 20-30% of their time reviewing code, and for good reason. Every review you complete unblocks a teammate, prevents bugs from reaching production, and shares knowledge across the team.
But here's the challenge: the default notification systems aren't designed for the way most engineers actually work. GitHub's notification system treats all notifications equally, whether it's someone commenting on a year-old issue or requesting an urgent review that's blocking a release.
The result? Important review requests get buried in noise, leading to delayed feedback, frustrated teammates, and ultimately slower team velocity.
Core Strategies for Managing Review Requests
1. Team Communication Channels
One of the most effective changes I've seen is creating a dedicated Slack channel for your team's pull request reviews. This might seem like overkill, but it offers several advantages over relying solely on automated notifications.
Here's why this approach works:
- Human-initiated requests are more intentional. When someone has to actively share their PR in a channel, they're signaling that it's actually ready for review—not just a work-in-progress they pushed up for backup.
- Context travels with the request. Your teammate can add a quick note about urgency, complexity, or specific areas they'd like you to focus on.
- Visibility for the whole team. Other team members can jump in if the original reviewer is unavailable, and everyone stays aware of what's in flight.
Set clear expectations about when to use this channel. A good rule of thumb: use the channel when your PR is ready for review and you need feedback within the next day or two. For non-urgent reviews or specific expertise requests, direct mentions still work well.
2. Notification Management
The vast majority of my career has been spent using GitHub for pull requests and as a code repository. And as I work there now, it is still my tool of choice. However I'm sure that these principles could easily be applied to other code repository platforms as well.
GitHub's notification system can be tamed, but it requires some intentional configuration. One of the best resources I've found for this is Ben Balter's approach to managing GitHub notifications.
Here are the key principles:
- Turn off noise, amplify signal. Disable notifications for activities that don't require your immediate attention, like issue comments on repositories you're watching. Focus your notifications on review requests, mentions, and direct assignments.
- Use email strategically. Configure email notifications only for high-priority events—like when you're specifically requested as a reviewer. This creates a separate, more urgent channel for important requests.
- Silence bots Silence the notifications that are less critical for immediate action, like Pull Request reviews from Dependabot if you only need to worry about them on a particular release cycle.
3. Personal Workflow Tips
Even with better notifications, you need a personal system for managing your review queue. Here's what works for me:
- Triage by urgency and complexity. When you see a review request, quickly assess: Is this blocking someone? How complex will this review be? Quick, non-blocking reviews can often be knocked out immediately, while complex reviews might need dedicated time.
- Time-block for reviews. Rather than doing reviews reactively throughout the day, consider setting aside specific blocks of time. This allows you to get into the right mindset and give more thoughtful feedback.
- Set response time expectations. Communicate and document your typical review turnaround time for your team. This might be "within 1 business day." Having clear expectations prevents misunderstandings and reduces anxiety on both sides. This is especially important on teams that have relatively little time zone overlap.
- Use draft status wisely. Encourage your team to keep PRs in draft status until they're truly ready for review. This reduces false alarms and helps everyone focus on PRs that actually need attention.
Making It Sustainable
The key to any system is making it sustainable long-term. Here are some strategies to avoid review burnout:
- Communicate your availability. If you're deep in a complex project or dealing with urgent issues, let your team know your review capacity will be limited. Most teams prefer transparency over silent delays.
- It's okay to decline or defer. If you're overwhelmed with review requests, it's perfectly acceptable to say, "I won't be able to get to this until Friday—can someone else take a look, or is that timeline okay?" Your teammates will appreciate the honesty.
- Balance reviewing with your own work. Reviewing code is important, but it shouldn't completely derail your own projects. If you find yourself spending more than 30-40% of your time on reviews, it might be time to discuss workload balance with your team.
- Learn to give efficient feedback. Not every review needs to be exhaustive. For smaller changes or experienced developers, a quick check for obvious issues and a thumbs-up can be sufficient.
Have comments or questions about this newsletter? Or just want to be internet friends? Send me an email at brittany@balancedengineer.com or reach out on Bluesky or LinkedIn.
Thank you for subscribing. It would be incredibly helpful if you tell your friends about this newsletter if you like it! :)