Why you reread the same code three times and miss the bug: the cost of forced familiarity

You open a small diff, go over the same lines several times, and still cannot explain exactly what changed. The change looks correct because it matches what you intended to write. But recognizing your own intention is not the same as verifying the code on the screen.

When that happens, do not do a fourth identical reading. First, find out whether the problem is visual fatigue or familiarity with the change. Then review the diff without immediately reconstructing the story already in your head.

Familiarity can help and hide things too

Knowing a file is not a problem in itself. Research by Alberto Bacchelli and Christian Bird on modern code review practices and challenges shows that understanding a change takes up a significant part of a review and that unfamiliar files require more context. For another reviewer, familiarity can make it easier to navigate the system and evaluate the change.

Here, however, the case is more specific: self-review immediately after writing the code. You know the goal so well that you may mentally fill in a missing condition, read the name you meant to use, or accept a flow because you remember an explanation that is not in the diff.

There is a useful analogy with learning. Dunlosky and coauthors' review of learning techniques rates rereading as a low-utility technique and describes diminishing returns from repeated, concentrated rereading. The study did not evaluate code, but it offers a practical warning: recognizing text you have already seen is a weak check when you need to explain it without cues.

Ask one simple question without opening the entire file:

> What behavior should this diff change, and where could that change fail?

If a small, localized change takes more than ten minutes and you still cannot answer in one sentence, stop rereading. Close the old context and write the answer. The unproductive loop becomes obvious when you can identify neither the new behavior nor the highest-risk section.

Take the 60-second test before pushing on

Not every difficulty comes from familiarity. Burning eyes, a headache, or characters that are hard to distinguish suggest that staying in front of the screen may not be a good choice. This test does not provide a medical diagnosis; it merely helps you decide whether the review should continue at that moment.

DevDojo suggests the 60- and 90-second timers used in this article as practical limits; they are heuristics, not laboratory findings.

For the 60-second test:

1. Close the diff.
2. Read a short paragraph unrelated to your code.
3. Close that text too and summarize it aloud or in writing.
4. If you cannot, stop the review and rest your eyes. If you can, reopen only the diff and try to name the changed behavior.

Difficulty with the unrelated text, especially when accompanied by visual discomfort, calls for a break. If you can summarize it but cannot explain your own diff, change how you review instead of insisting on the same reading.

Read the diff in silence before opening the old file

Opening the complete file at the outset provides context, but it also retrieves the narrative you already know. In an immediate self-review, it becomes easier to justify the change through the original intention than to examine what was added and removed.

Read only the diff in silence for 90 seconds before opening the old context. The timer prevents endless scrolling and forces an initial conclusion.

In the terminal, start like this:

git diff --stat
git diff

During those 90 seconds, do not open the files. At the end, complete this sentence:

Isto deveria fazer X; o risco está em Y.

For example:

Isto deveria aumentar o timeout padrão do cliente; o risco está nos fluxos que esperam uma falha rápida.

Only then open the surrounding lines to check contracts, conditions, and side effects. If the context shows something different from what you wrote, that discrepancy has already exposed a failure of understanding, even if it is not a bug.

Turn previous mistakes into short cues

A generic best-practices list tends to steer a review toward easy items such as formatting and names. Instead, create a list of three to five mistakes you actually made or almost missed.

These examples show only the format:

• inverted condition after renaming a variable;
• exception logged and ignored;
• date handled without a time zone;
• difference between a null value and an empty collection;
• boundary that excludes the first or last item.

Replace the examples with your own history and turn each item into a short question: “Did I invert the condition?” or “Does this date have a defined time zone?” For one week, read the list before every self-review and look only for those patterns in the diff.

At the end of the week, keep the items that exposed an omission or prompted a relevant check. Remove those that never applied. This keeps the list short and tied to the mistakes that actually fool you.

Avoid replacing one rereading habit with another

The routine loses its usefulness when it changes only the appearance of the habit. Watch for these detours:

• Scrolling through the diff for 90 seconds without forming a hypothesis. When time is up, complete the sentence, even if the answer is incomplete.
• Opening the old file to “check just one thing.” Write down the question and finish the isolated reading first.
• Filling the list with style rules. Prefer behavioral failures that have already occurred in your code.
• Treating the technique as a guarantee against bugs. It organizes self-review, but it does not replace tests or another person's review.

If you still cannot state the changed behavior, do not restart the process. Wait until the next day or ask someone else to read the change with the objective and reason stated explicitly.

Run a 15-minute experiment for five days

Set aside 15 minutes a day for five days. Choose a small change or a recently modified section and follow this order:

1. use the 60-second test if you are unsure about fatigue;
2. read only the diff for 90 seconds;
3. write down the expected behavior and the main risk;
4. consult your personal list;
5. open the surrounding context.

Use a small log to record what changed:

At the end of the five days, compare the time needed to explain the change and check whether the isolated reading or the list revealed something missed on the first pass. Also record the days when the method did not help.

Adopt the routine only if it reduces the time to a clear explanation or reveals at least one previously missed omission. If neither result appears, discard the rule and do not turn the timer into a ritual.