Chapter 2: Author-Side Practices: Small PRs and Self-Review

Why this matters

Code review quality isn't determined solely by the reviewer — the author's own practices before a PR is ever opened have an enormous effect on how good a review it's possible to receive. An author who submits a sprawling, unreviewed-by-themselves-first PR is setting the review up to fail before a reviewer even opens it, regardless of that reviewer's skill or diligence.

Small PRs: the single highest-leverage author practice

[BEGINNER] Directly building on the companion Coding Standards book's Chapter 8: PR size has a well-documented, non-linear effect on review quality — a reviewer facing a 2,000-line diff can only realistically skim, while a reviewer facing a 150-line diff can genuinely reason about every line. This means an author who keeps PRs small is directly, materially improving the quality of feedback they'll receive, not just being considerate of the reviewer's time.

Instead of one PR: "Add user profile feature" (1,800 lines: data model,
migration, API endpoints, frontend components, tests, all together)

Consider a sequence:
  PR 1: "Add user profile data model and migration" (120 lines)
  PR 2: "Add user profile API endpoints" (200 lines)
  PR 3: "Add user profile frontend components" (350 lines)
  PR 4: "Add user profile tests" (150 lines, or integrated into 1-3)

Each PR is independently reviewable in a focused sitting, and a problem
found in PR 1 doesn't require re-reviewing 1,800 lines of DOWNSTREAM code
built on top of a flawed foundation.

[SENIOR INSIGHT] Splitting work this way requires genuine planning skill — deciding how to decompose a feature into independently-reviewable, independently-mergeable (or at least independently-understandable) increments is itself a design skill, not just a mechanical chopping-up of an existing large diff after the fact. An author who plans their branching/commit strategy around reviewability from the start produces much more naturally splittable work than one who writes the whole feature first and tries to retroactively slice it into PRs.

Self-review: catching your own issues before anyone else sees them

[BEGINNER] Before requesting review, an author should review their own diff exactly as if they were an external reviewer — reading the actual diff (not just trusting memory of what was written), specifically looking for issues that are embarrassing or wasteful for a reviewer to have to point out: leftover debug statements, commented-out code, obvious typos, an accidentally-included unrelated change.

// Exactly the kind of issue self-review should catch BEFORE a reviewer ever sees it:
function calculateTotal(items: Item[]): number {
  console.log("DEBUG: items =", items);  // forgotten debug statement
  // const oldImplementation = items.length; // dead, commented-out code
  return items.reduce((sum, item) => sum + item.price, 0);
}

[IN PRACTICE] Self-review has a second, less obvious benefit beyond catching embarrassing leftovers: reading your own diff as a stranger would often surfaces genuine design issues the author didn't notice while writing the code incrementally, function by function — seeing the whole diff at once, in the "reviewer" mental mode rather than the "author" mental mode, engages a different, more critical way of reading than the one used while actively writing.

Writing a PR description that does real work

[BEGINNER] Chapter 3 covers this in full, but it belongs here too as an author-side discipline: a PR with no description, or a description that just restates the title, forces every reviewer to reconstruct context (why this change, what alternatives were considered, what's out of scope) from the diff alone — exactly the same "why, not what" principle from the Coding Standards book's Chapters 4 and 8, applied to the PR description specifically.

Common mistakes

1. Submitting large, unplanned PRs and relying on the reviewer to somehow manage the resulting review burden — PR size is substantially an author-side responsibility, not something a reviewer can fully compensate for after the fact.
2. Skipping self-review entirely, leaving embarrassing, easily-caught issues (debug statements, dead code, typos) for a reviewer to point out — wasting review bandwidth on issues the author could have caught alone.
3. Writing all the code for a large feature first, then attempting to retroactively slice it into small PRs — this produces awkwardly-split, hard-to-independently-understand pieces; planning the decomposition from the start produces much more naturally reviewable increments.
4. Treating self-review as a check for typos alone, missing its deeper value as a chance to re-read the whole diff in a more critical, "reviewer" mindset that can surface genuine design issues the author missed while writing incrementally.

Checklist: author-side practices before requesting review

1. Plan how a feature will decompose into small, independently-reviewable PRs from the start, rather than writing the whole thing and retroactively slicing it.
2. Read your own full diff before requesting review, specifically looking for debug leftovers, dead code, typos, and accidentally-included unrelated changes.
3. Use self-review as an opportunity to re-evaluate design decisions with fresh eyes, not just a typo check.
4. Write a PR description that explains the "why," not just a restatement of the title (Chapter 3 covers this in full).

Discussion / interview questions

1. "Why does PR size matter, and whose responsibility is it to manage?" Strong answer: Review thoroughness drops sharply, non-linearly, as diff size grows — this is substantially an author-side responsibility, since it requires planning a feature's decomposition into independently-reviewable increments from the start, not something a reviewer can fully compensate for after receiving an oversized PR.

2. "What should an author look for during self-review, before requesting review from someone else?" Strong answer: Embarrassing, easily-caught issues (debug statements, dead/commented-out code, typos, accidentally-included unrelated changes) at minimum, but also a genuine re-evaluation of design decisions by reading the whole diff with fresh, "reviewer" eyes rather than the incremental "author" mindset used while writing it.

3. "How would you approach splitting a large feature into a sequence of reviewable PRs?" Strong answer: Plan the decomposition from the start of the work (a data-layer PR, then an API-layer PR, then a UI-layer PR, for instance), rather than writing the whole feature first and attempting to retroactively carve it into pieces — early planning produces much more naturally independent, understandable increments.

4. "Why might reading your own PR's diff before requesting review reveal design issues the author didn't notice while writing it?" Strong answer: Writing code happens incrementally, function by function, in an "author" mindset focused on the immediate piece being built; reading the whole diff at once in a "reviewer" mindset engages a more critical, holistic evaluation that can surface issues invisible from inside the incremental writing process.

Chapter summary / cheat sheet

• Small, well-planned PRs are the single highest-leverage author-side practice for review quality — this requires decomposition planning from the start, not retroactive slicing.
• Self-review (reading your own full diff before requesting review) catches embarrassing leftovers and, more importantly, can surface genuine design issues via a more critical "reviewer" mindset.
• A PR description should explain "why," not just restate the title — this is an author responsibility, covered in full in Chapter 3.
• Review quality is substantially shaped before a reviewer ever opens the PR — these author-side practices aren't a courtesy, they're a direct lever on how good a review is actually possible to give.

---