Code Review Culture and PR Best Practices

Code review is not gatekeeping — it's how teams learn together, transfer ownership, and keep quality high. A good review culture lifts the whole team; a bad one creates bottlenecks and resentment.

1) Keep it small (under 400 lines if possible). 2) Write a clear description: why, what, how to test. 3) Link the ticket. 4) Add screenshots/videos for UI changes. 5) Self-review your diff before requesting reviewers.

Use the same conventional prefixes as commits: feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component. Many teams generate changelogs from these.

Most teams use a PR template — install in .github/pull_request_template.md.

Before requesting reviewers, walk through your own diff line by line. Add comments explaining non-obvious choices. Often you'll catch your own bugs before someone else has to.

A 2000-line PR rarely gets a thorough review. Split into: 1) refactor (no behaviour change), 2) new behaviour, 3) UI polish. Each easier to review and revert.

Frame as questions, not orders: 'What do you think about extracting this to a hook?' beats 'extract this'. Distinguish must-fix from nice-to-have. Use prefixes: nit:, question:, blocker:.

'This is confusing' tells the author nothing. 'I had to read this 3 times to understand the early return — could we extract a guard clause?' gives them something to act on.

Comment positively on clever solutions, good naming, helpful tests. It encourages those patterns and softens the rest of the feedback. PRs that get only criticism feel adversarial.

Prettier handles formatting. ESLint handles style. Don't waste review cycles on tabs-vs-spaces. If a style rule keeps coming up, encode it in the linter.

Tests are code too. Make sure new code has tests. Check tests are actually exercising the right thing — many tests pass even when broken because they assert on the wrong thing.

Respond to every comment — even with just a thumbs-up emoji. Push back on suggestions you disagree with (you wrote the code; you might have context). Mark resolved threads as resolved. Update the PR description if scope changes.

Review within one business day. Stale PRs lose context — the author has moved on, the branch needs rebasing. Big PRs that sit a week always become hellish merges.

GitHub's suggestion feature lets the author accept a fix with one click. Much faster than 'change this line to X' in prose.

Approve when: the code is correct, tests pass, you understand the change, it's safe to merge. Approving means you're co-owning the result. Don't 'rubber stamp' — if you didn't read it, say so.

What's the recommended attitude when giving code review feedback on something you'd write differently?

Author: small, well-described PRs with screenshots and tests. Self-review first. Reviewer: constructive, question-based feedback. Distinguish blocker from nit. Praise the good. Skip style — let tooling handle it. Review within a day. Approve only when you understand. PR templates standardise the process. Reviews are collaboration, not gatekeeping.