Code Reviews: More Than Just Catching Bugs

Photo by Desola Lanre-Ologun on Unsplash

One very good way to learn and level up, especially working with teams, is code review. I see code review as an opportunity to learn from my teammates and stay in the loop on the new features, improvements, and products we’re building. I’ve worked at places where some team members shy away from reviewing code intentionally, because they assume they can’t review code for someone more senior or more experienced than them, or for other interesting reasons.

Personally, code review is much more than just reviewing the code. If that’s all it were, we might as well let Copilot do the job, or spin up multiple Claude Code subagents, give them some code review skills and instructions per the company’s engineering practices, and call it a day. Agents can point out syntax errors, grammatical errors, and a host of similar things. But code review goes beyond that.

Why code review matters

With code review:

You get to learn from your peers.
You stay updated on new features, products, or improvements your teammates are shipping.
Your feedback on testing could be crucial if something was missing, or if you think something could be done a better way.
Everyone reviews pull requests (PRs) differently. Your approach could help spot issues or bottlenecks that someone else just didn’t see, or that only you’d catch given your particular experience.
If you’re working on an existing solution where backward compatibility can’t be taken lightly, reviewing the code and following the flow could help you spot things that would be catastrophic in production. Edge cases like these often require context that no single person on the team has alone.

These are just a few of the upsides. In my experience, engineers who fail to review code typically struggle because they don’t see code review as part of the job. It’s often not written into your contract, but it feels like an unspoken rule, since you’ll also work on features, products, and improvements that require other teammates to review your code too.

One thing that’s always worked for me personally: start the day with code reviews to get them out of the way, or end the day with them to make sure people’s work doesn’t spill into the next day. The urgency from the PR owner matters too. If we’re being honest, everyone is and will be busy, but it’s the empathy and understanding around that busyness that keeps things moving.

My PRs are taking longer to get reviewed

With the recent shift in company culture worldwide, now that AI is baked into our workflow, we can churn out features, fixes, improvements, and products in hours if not minutes. Tasks that used to take days now take far less time, which means one thing: a lot more PRs to review. Nobody’s shipping to production or staging without a confident review, and that’s not something we compromise on just because the work got done fast and “AI says it’s good.”

If you find yourself in this position, you’re not alone. One practical approach that’s worked for me is to relentlessly chase (not harass) your reviewers. The onus is on you, the owner, to get your work shipped; ownership is a quality every team wants. I know it can feel like begging people to do their job, but work isn’t linear. Everyone is busy trying to hit their own goals and ship their own work too.

Another common pattern: someone starts reviewing your code, then gets pulled away, by a call, lunch, standing up from their desk, whatever, and when they’re back, they’ve moved on to their own task and forgotten to return. This is exactly why the relentless, gentle nudging helps.

If you’ve done all this and your PR still isn’t getting reviewed, escalate to your PM or tech lead. At that point it’s a blocker, and unblocking you is their job.

My trusted secrets to getting PRs reviewed faster

Keep the file count small. Review speed noticeably picks up when you have 2-3 files changed.
Give your PR description real context. A technical spec, or a Linear/JIRA ticket, plus a clear explanation of what changed, why, and how you approached it.
Add screenshots. As a frontend engineer, screenshots (web and mobile) go a long way, they give the reviewer a visual cue for what they’re about to review. A Figma link helps too.
Write a detailed “how to test” section. Many features can be tested in different ways, and some aren’t testable on certain accounts or environments, or need a specific setup. Spell that out.
Use PR stacking for large changes. Break big changes into several smaller PRs that target each other in sequence. Explicitly document the review flow on each PR, with links to the dependent PRs.
Ask yourself: what would the reviewer need if I weren’t around? A lot of PRs sit longer than they should simply because the reviewer isn’t armed with enough context. Link the Slack thread, the conversation, the bug report, anything relevant. Don’t assume they have the background you do.
Review your own PR before anyone else does. It sounds strange, but it works. Read through your own diff like you’re the reviewer. You’ll often catch improvements, inconsistencies, or things that don’t quite match how the team codes, and you can fix them before anyone else has to point them out.

None of this works if we treat code review as someone else’s job. It’s not a tax on shipping, it’s part of shipping. The teams that do it well aren’t the ones with the strictest process; they’re the ones where reviewing each other’s work is just something everyone owns, without being asked.

So, therefore: review your colleague’s code today. Their code is not going to review itself, and no, asking Copilot to review it and “approve” is not enough!.