Skip to main content

Code Review With Yourself: The 24-Hour Read-Through

What This Concept Is​

A 24-hour read-through is a deliberate self-review of code you wrote roughly a day earlier, performed with the same rubric you would use to review a teammate's code. The key word is delay: the gap destroys the short-term memory that otherwise makes bugs and unclear structure invisible to the author.

The rubric is the one from S3 M05, mapped onto Google's engineering-practices categories:

  • Correctness -- does the code do what it claims?
  • Clarity -- can a future reader follow it?
  • Design -- is the shape right, or is it pattern salad, duplication, or leaky abstraction?
  • Tests -- do the tests actually prove behavior, and at the right level?

The output is a short list of review comments on your own PR, each tagged by rubric category, each specific enough to act on. Google's "Standard of Code Review" is the canonical articulation: reviewers (and self-reviewers) look for things that improve the health of the system over time, not a narrow definition of "correct." The rubric is what makes that judgement repeatable.

Why It Matters Here (In the Capstone)​

Capstones are often solo or near-solo. Without a reviewer, your code never gets a second pair of eyes. The 24-hour read-through is the cheapest substitute. It will not replace a real reviewer, but it catches:

  • obvious bugs you did not see because you were still thinking about the change;
  • names that only made sense to yesterday-you;
  • missing tests for edge cases that occurred to you but you did not write down;
  • refactoring candidates that should go in the ledger (Concept 15).

This module requires the read-through to happen before merge or (for already-merged capstone commits) within 48 hours.

Concrete Example(s) -- from a real capstone​

Yesterday's PR: added POST /tasks with validation, a service method, and a repository call, plus three tests.

Today, re-open the PR diff before starting new work. Read each file top to bottom, pretending it was written by someone else. Leave self-comments. Examples:

  • Clarity: task_svc.py:34 -- "variable t used for both incoming payload and saved row; rename to payload vs saved."
  • Correctness: task_svc.py:41 -- "we do not check that due_date is in the future; spec says it can be past -- verify."
  • Design: task_svc.py:58 -- "this repo method is now called from three places; consider moving validation into the service boundary so the repo stays dumb."
  • Tests: test_tasks.py -- "no test covers unicode title; see BUG-2026-04-04-01 -- add a regression test."
  • Ledger: "error translation is ad-hoc; consolidate to a middleware -- not this week -- add ledger entry."

Five comments in about 20 minutes. Two are acted on today; one becomes a ledger entry; two are filed as small follow-up PRs. That is the typical shape.

Common Confusion / Misconceptions​

The biggest misconception is "I will just review as I write." You cannot. Fresh code is invisible to its author in the same way a typo is invisible to its writer -- you see what you meant, not what is there. The delay is what makes the read-through valuable.

A second is trying to do it without a rubric. Free-form reading produces mostly nits. The rubric forces you to examine correctness, clarity, design, and tests as separate concerns and catches different kinds of issue in each pass.

A third is over-correcting. A self-review is not a request to rewrite yesterday's work; it is a request to catch the two or three items that matter. Not every review comment must be acted on -- some go to the ledger, some are deliberately declined.

A fourth is doing the read-through at PR time. That defeats the delay; the whole point is that fresh code is invisible. Schedule the review explicitly for the next morning.

How To Use It (In Your Capstone)​

Daily practice:

  1. Open the PR or commit you made roughly 24 hours ago. Do not open it sooner.
  2. Spend 15-25 minutes reading the diff as if it were someone else's.
  3. Walk the rubric: correctness pass, clarity pass, design pass, tests pass.
  4. Leave specific comments, each tagged with a rubric category.
  5. Decide for each comment: fix now, small follow-up PR, ledger entry, or decline.
  6. Take action on the "fix now" and "small follow-up" list the same day.
  7. Once a week, do a broader read-through covering the whole week's diffs, looking for patterns rather than individual issues.

A Worked Read-Through on a Small PR​

Yesterday you merged a 120-line PR that added GET /tasks/{id} with a 404 path and two tests. This morning you open it.

  • Correctness pass (5 min). Trace the happy path by hand: request -> handler -> service -> repo -> response. Then trace the 404 path. You notice: the handler returns 404 when get_task returns None, but get_task actually raises NotFound. Comment: "Correctness -- task_handler.py:22 raises, does not return None. 404 branch is dead; add a unit test that hits NotFound and returns 404."
  • Clarity pass (5 min). Rename: h -> task_id in three places. Comment: "Clarity -- task_handler.py:17,19,22 -- parameter h is from an earlier copy/paste. Rename."
  • Design pass (5 min). Ask: is this handler too smart? It catches three exception types. Comment: "Design -- consider middleware for NotFound / ValidationError so handlers stay dumb. Ledger entry, not this PR."
  • Tests pass (5 min). Assertion density check. Comment: "Tests -- test_get_task.py:30 calls the endpoint but asserts only status code. Add an assertion on the response body (title + id)."

Five targeted comments in 20 minutes. Two are fixed same-day; two become follow-up PRs; one becomes a ledger entry.

Anti-Patterns to Recognize​

  • "Looks fine." If the read-through produces no comments, you did not read it.
  • "Rewrite everything." If the read-through produces thirty comments, you are not self-reviewing, you are relitigating the PR.
  • Read-through at PR time. Doing the self-review as the last step before merging defeats the delay.
  • No rubric. Free-form reading produces mostly style nits.

When the Rubric Fights You​

If every category produces mostly "looks fine", pick a harder lens:

  • compare the PR's intent (from the commit message) against what it delivered -- did you do what you said?
  • read only the tests. If they were the only artifact, would a reader understand the feature?
  • read only the production code. Would it survive being deployed with no tests?
  • pretend the reviewer is hostile to the change. What is the strongest critique?

Rotate lenses weekly. The goal is to keep the read-through sharp when your defaults soften.

See also (integrative)​

External references:

Check Yourself​

  1. Why is the 24-hour delay essential to the read-through?
  2. What four categories does the rubric force you to examine, and in what order?
  3. Why is "this feels ugly" a bad self-review comment?
  4. If the read-through produces thirty comments, what is the right response?
  5. Which of the four categories is most often under-examined in solo capstone review, and why?

Mini Drill or Application (Capstone-scoped)​

  1. Tomorrow, do a real 24-hour read-through on today's PR: set a timer for 25 minutes, walk the rubric, and leave at least five specific comments each tagged by category.
  2. Act on the "fix now" items the same day; file the rest as follow-up or ledger entries.
  3. At the end of the week, do the weekly broader read-through across all merged PRs and list one pattern you found.
  4. Rotate the "harder lens" once per week (test-only read, production-only read, hostile-reviewer read) and note which lens caught the most issues.
  5. Track in your journal how many review comments became ledger entries vs same-day fixes vs declined -- over four weeks you will learn where your defaults drift.

Source Backbone​

Capstone implementation applies earlier code-quality, testing, and refactoring material. These books are the source backbone for that practice.