Code Review Best Practices for Authors and Reviewers

Code review is the most underrated career skill in engineering. The way you write and respond to reviews tells your team more about you than any standup or design doc. Yet most engineers treat it like a chore.

Done well, code review catches bugs, spreads knowledge, and quietly mentors junior engineers. Done badly, it becomes a power game, a bottleneck, or a polite rubber stamp. The difference is mostly habits, not talent.

This is the playbook I wish someone had handed me on day one.

Part one: being a good author

The author owns the experience. If your PR sits for three days, that is often a signal you made it hard to review, not a signal your reviewers are lazy.

Keep PRs small

The single biggest predictor of a fast, high-quality review is the size of the diff. Under 200 lines: reviewers actually read it. Over 500 lines: they skim. Over 1,000 lines: they LGTM and pray.

If your change is large, split it. Refactor in one PR. Add the new feature in the next. Add the tests in a third if needed. Stacked PRs are not a sign of inexperience. They are a sign of respect for your reviewer’s time.

Write a description that earns the read

A bad PR description is just the ticket number. A good one answers three questions in the first paragraph:

1. What does this change?
2. Why are we doing it?
3. What should the reviewer focus on?

If there are screenshots, attach them. If there are performance numbers, attach them. If there is a tricky decision, call it out and explain the alternatives you rejected.

This is also where you note things like, “I left the legacy handler in place; will delete in a follow-up.” Reviewers should never have to guess your intent.

Self-review before you ask others

Open your own diff in the PR view. Read it like you are seeing it for the first time. You will catch typos, debug logs, commented-out code, and at least one “wait, that is not how I meant to write this” every single time.

Self-review takes five minutes and saves a review cycle.

Respond to feedback like an adult

Not every comment is correct. Not every comment is wrong. Read each one charitably. If you disagree, say why with evidence, not vibes. If you agree, just say “good catch” and fix it.

Mark conversations resolved when you have addressed them. Do not leave 40 open threads and ask the reviewer to figure out what is left.

Part two: being a good reviewer

The reviewer’s job is to make the code better and the author smarter. Not to prove they are smart.

Review in priority order

When you open a PR, look at things in this order:

1. Correctness. Does it do the thing it claims to do?
2. Design. Is this the right approach, or is there a simpler one?
3. Readability. Will someone understand this in six months?
4. Style. Naming, formatting, conventions.

Most reviewers do this in reverse. They nitpick the variable names in line 42 and miss that the entire approach is wrong. If the design is broken, do not bother commenting on style. Fix the design conversation first.

Frame comments as questions when you can

There is a huge difference between these two comments:

This is wrong. Use a map instead.

versus

Could this be a map lookup instead of a loop? It would be O(1) and easier to read.

Both are technically the same. The second one preserves the author’s autonomy, invites a conversation, and does not assume the author missed something obvious. It also makes it easier for the author to push back if there is a reason you missed.

Phrasing matters when half the team is reading along.

Distinguish blocking from non-blocking

Prefix optional comments. “Nit:” for style. “Question:” for things you want to understand. “Suggestion:” for ideas. Save plain comments for things that genuinely block the merge.

If everything you write reads as blocking, the author cannot prioritize. They will treat every nit as a must-fix and resent the review.

Approve when it is good enough

Engineers love to find one more thing. Resist. If the PR is correct, well-designed, and readable, approve it. Perfect is the enemy of merged. Open a follow-up issue for ideas that are not strictly necessary.

You are not the last line of defense. CI, QA, monitoring, and future PRs all exist.

Conversations about performance, not perfection

Performance comments often turn into religion. “This loop is O(n squared)!” Maybe. But on what input size? In what code path? Is this hot or cold?

Before you push back on performance, know the actual complexity and the actual data size. If you need a refresher on reasoning about cost, read big-O notation explained and the broader what is DSA overview. Without those, your review comments are just guesses with attitude.

Also: when you flag a perf concern, suggest a fix or a measurement. “Could we benchmark this?” is more useful than “this seems slow.”

When to fight, when to fold

Some review disagreements are worth a fight. Most are not. Use this filter:

• Correctness or security: fight. Be specific, be calm, be persistent.
• Architecture or maintainability: discuss. If you cannot agree, escalate to a third engineer.
• Style preferences: fold. Or push them into the linter so a human never argues about them again.

A senior engineer who fights every style nit will be avoided. A senior engineer who fights only on correctness will be trusted.

Reviewing PRs from juniors

Different mode. Juniors are watching how you behave more than reading your comments. A few habits:

• Praise something specific in the PR. Not “nice work.” Something like “good test coverage on the edge cases.”
• Explain the why behind your suggestions. Not just “use a map” but “use a map because lookups will be called in a hot loop.”
• Resist rewriting their code in the comment. Point at the issue, let them solve it.

You are mentoring whether or not the meeting is on the calendar.

A note on review speed

Reviewing within a few hours of being tagged is one of the highest-leverage habits you can build. It unblocks teammates, builds goodwill, and makes you the person people want to work with. Review fatigue is real, but a 10-minute review now beats a 30-minute review tomorrow because you forgot the context.

Two daily slots, morning and after lunch, is plenty for most teams.

How code reviews show up in interviews

When you switch jobs, you will be asked about code review. “Tell me about a hard review you gave or received.” Have a story. The same skills that make you a good reviewer make you a good interviewer signal. Pair this with the broader behavioral prep in dev interview prep basics, and update your resume to mention mentoring through reviews if it has been a real part of your impact.

Wrap up

Code review is where engineering culture lives. Small PRs, clear descriptions, charitable comments, fast turnarounds, and the discipline to approve when it is good enough. These habits are simple, free, and rare.

Do them consistently and you will be the engineer everyone wants to ship code with. That is worth more than any framework or buzzword on your resume.