Code reviews are one of the most powerful tools we have as engineers. When they’re done well, they catch bugs early, spread knowledge across the team, and raise the bar on quality. When they’re done poorly — or worse, just for show — they become either a rubber-stamp formality or a painful bottleneck that nobody wants to deal with.

I’ve had this conversation with many engineers I’ve mentored, and I want to lay out some key principles I always try to instill — what responsibilities fall on the developer, what reviewers owe in return, and how both sides can make the process faster, smarter, and less frustrating.

A PR Is Not a Delivery Truck — It’s a Conversation

Let’s start with a mindset shift: a pull request isn’t the “final drop” of your work. It’s the start of a conversation with your team. Your job as the developer is to invite your reviewer into your thinking, and their job is to evaluate that thinking with a critical and constructive lens.

You are not “done” when you open a PR. You’re ready to collaborate.

Responsibilities of the Developer

As the author of a pull request, your responsibilities aren’t limited to writing code that compiles and passes tests. Here’s what you actually owe your reviewer and your team:

  • Clarity: Make your code as readable as possible. Add comments for anything complex. Describe your intent in the PR summary so reviewers don’t have to reverse-engineer it.
  • Focus: Keep the PR small and limited in scope. Don’t sneak in unrelated cleanups or refactors. If you’re fixing a bug, fix the bug. If you’re shipping a feature, ship that feature.
  • Context: Explain what problem you’re solving, how you approached it, and any relevant decisions or trade-offs.
  • Ownership: If you touch a piece of code — even just slightly — you own it now. And that brings us to Boy Scouting.

Don’t Be a Boy Scout (Really)

You may have heard the phrase: “Always leave the code better than you found it.” That’s the so-called “Boy Scout Rule” in software development. Sounds nice, right?

Here’s the problem. Everything in moderation. Especially Boy Scouting. If you do too much Boy Scoutinging it actually causes more problems with the flow of your team’s work. There is a reason why its called Boy Scouting, it’s a bit of a cynical term playing of the naive altruism sometimes associated with Scouting. It’s rooted in the idea that no good deed goes unpunished and the age old idiom — “No good deed goes unpunished”. Yes it’s a very cynical take but there is some truth to it.

You clean up some legacy code while fixing a bug? Now that whole mess is your problem. Reviewers nitpick it. Bugs emerge in untouched logic. You become responsible for tech debt you never signed up for.

This happens all the time.

So no, I don’t recommend Boy Scouting. If you see a mess, don’t casually fix it on the side. Flag it. Log it. Open a separate ticket or tech debt PR. Establish a process to address quality issues outside of the feature you’re delivering. Don’t blur the boundary between focused delivery and opportunistic cleanup.

Because once you touch code, you own it. And you need to be prepared to defend it, explain it, and maintain it.

Responsibilities of the Reviewer

As a reviewer, your job is not to approve as fast as possible — it’s to catch problems, provide insight, and hold the quality bar.

You owe the team:

  • Engagement: Actually read the code. Understand the intent. Don’t skim. Questions, not assumptions: If something looks off, ask why. Don’t assume it’s correct.
  • Relevance: Avoid nitpicking trivial details — thats what things like SonarQube are for (if you don’t have something like this to catch the trivial code smells, make sure to set it up). We should be focus on design, correctness, maintainability, and clarity and not wasting time with the mundane.
  • Timeliness: If you’re assigned a PR, make time for it. A thoughtful, timely review is better than a rushed review — or no review at all. If you don’t have time to do a review right now, say so. Let the developer know when you can get to it. Silence kills momentum.

Small PRs Win

This cannot be overstated: smaller pull requests get better reviews.

The more lines you change:

  • The harder it is for someone to understand your intent.
  • The easier it is to miss bugs.
  • The more likely it is to stall in review limbo.

If your PR takes more than 20–30 minutes to review, it’s too big. Break it into smaller pieces. Use feature flags, stubs, or scaffolding to get incremental progress in. And if your PR has to be big — because sometimes it does — don’t just submit it and walk away.

Walk the reviewer through it. Call out tricky areas. Pair if needed. A large PR is a heavy lift; don’t expect someone else to do all the lifting for you.

Tips to Smooth the Review Process

If you’re working with a competent reviewer, here’s how to make the review go faster and better:

  1. Explain your changes clearly in the PR description.
  2. Avoid surprise cleanup or refactors — especially in unrelated areas.
  3. Leave TODOs and flags in code where cleanup is needed, instead of fixing it mid-PR.
  4. Request feedback on specific concerns, not just generic review.
  5. Follow up on review comments quickly, or at least acknowledge them.

The more you reduce ambiguity, the easier it is for your reviewer to focus on what matters.

When Teams Get Code Review Wrong

When code review goes sideways, it usually looks like one of two things:

  • Reviews are rushed and ineffective: The code gets in, but nobody really looked at it. Bugs and regressions become frequent.
  • Reviews are slow and painful: Nobody wants to review. PRs sit untouched. Developers feel blocked. Morale drops.

And in most dysfunctional teams, both are happening at once. Why? Because the reviews are too large, unfocused, or treated like a chore. Reviewers are overwhelmed. Developers feel adversarial. The process breaks down.

A good code review culture is proactive. Small PRs. Clear expectations. Mutual respect. Tight feedback loops.

Conclusion

Code review isn’t just a tool — it’s a trust exercise. It only works when both sides respect the process and each other.

As a developer, it’s your job to make your reviewer’s life easier. As a reviewer, it’s your job to give the developer thoughtful, actionable feedback. The codebase gets better only when both roles show up with care and clarity.

So stop throwing work over the wall. Stop “Boy Scouting” your way into ownership you didn’t ask for. Start treating the review process like a professional ritual or a checkbox— it deserves your full attention.

Because great developers don’t just write great code — they write it together on a great team.