Logging Code Review Feedback to Find Your Patterns

2026-10-21 · Yesterself

Most advice about how to take code review feedback is advice about your feelings during the review. Breathe. Assume good intent. Remember the comment is about the code, not you. That is fine as far as it goes, and it goes about ten minutes.

The problem it does not touch is that a single review is almost useless as information. One comment about a variable name tells you nothing. Forty comments about variable names, spread across four reviewers and three months, tells you something specific enough to fix on a Tuesday afternoon.

So stop trying to extract the lesson from each review. Extract nothing. Just log the comment and move on. The lesson is in the pile.

The format: one tagged line per comment

When a review lands, you already read every comment once to address it. Add a second pass that takes about ninety seconds for a normal review. For each comment worth counting, write one line:

2026-10-14 — naming — R. — "this reads like a boolean but returns a list" — accepted

Five fields, all short:

• Date. So you can see drift over time.
• Tag. One word, from a list you keep small. This is the field that does all the work.
• Reviewer. Initials are enough. You are not building a case against anyone; you are checking whether a pattern belongs to you or to a relationship.
• The comment, quoted or paraphrased in under a dozen words. Quoting matters more than you would think — your paraphrase six weeks later will have quietly sanded off whatever stung.
• What you did. Accepted, changed differently, disagreed, deferred.

Start with about eight tags and resist inventing more. Something like: naming, structure, tests, errors, performance, style, scope, docs. If you find yourself wanting a ninth tag every week, you are describing individual comments instead of sorting them, which defeats the counting.

Skip the pure noise. A typo catch does not need a line. A bot complaining about line length does not need a line. Log the comments a human chose to write.

Where to keep it

Anywhere you will actually open. A plain text file, a note, a page in a paper notebook, a spreadsheet if you like sorting. What matters is that it is one place and it is not the pull request, because pull requests scatter and archive and become unsearchable across repository moves.

Keep it separate from your other work notes too. The value here is density: sixty lines that are all the same shape, so the shape of the pile becomes visible. Mixed into a general work journal, the same sixty lines disappear. If you already keep a debugging log or a learning log for a new codebase, this is a third narrow log, not a section of those.

If the line-per-item rhythm feels familiar, it is the same discipline as rapid logging — short entries, consistent shape, sorted later.

Reading the histogram

At the three-month mark, count the tags. Then count reviewer-by-tag. You are looking for one of a handful of shapes, and each one calls for something different.

One tag dominates everything

Forty naming comments and nine of everything else. This is the best possible result, because it is a single fixable habit, and habits that produce forty comments produce them for a reason you can usually name in one sentence once you look at the forty quotes together. Read them in a row. The sentence is often something like I name things after how I built them rather than what the caller gets.

Fix it upstream, not in review. Add the check to whatever you do before you open a pull request.

One reviewer owns one tag, and nobody else raises it

Every test comment you have received in three months came from the same person. Two readings are possible and the log cannot distinguish them: either that reviewer is the only one who reads your tests carefully, or that reviewer has a standard the rest of the team does not share.

Do not resolve this by guessing. Take three of the quoted comments to that person and ask what they are watching for. That conversation goes very differently when you open it with evidence you collected rather than a feeling that they are hard on you.

The tags are evenly spread and thin

Six or seven comments in each of eight categories, no concentration anywhere. This usually means the reviews are working and there is no systemic habit to fix. That is a legitimate outcome. Stop the log, or downgrade it to a line a week.

A tag that is thin but always ends in "disagreed"

Small count, high friction. Scope comments are the classic case — you keep being told a change does too much, and you keep believing it does not. A pattern of disagreement is worth more attention than a pattern of easy fixes, because it is where your model and the team's model actually differ. Write a paragraph about it, once, and see whether it survives your own reading a month later.

A tag that appears only after a date

Nothing about errors until August, then eleven comments. Something changed: a new codebase area, a new reviewer, a new expectation nobody announced. The date column is the only thing that shows you this, which is why it is worth the five characters.

What the log is not for

It is not a performance record and it is not a grievance file. The moment you start writing it for an audience — a manager, a promotion packet, an argument — it stops being accurate, because you will quietly stop logging the comments that make you look bad, and those are the ones with the pattern in them.

It is also not a scoreboard against yourself. A month with more comments is usually a month with harder changes or a more attentive reviewer. Volume is not the signal; distribution is.

Where Yesterself fits

Yesterself is a journaling app built on a single loop: each morning it delivers one letter drawn from your own past writing, and your evening reply becomes tomorrow's mail. It is not a review tracker, and this log does not need an app. But the retrospective habit is the same one — the value of a note is mostly in meeting it again later, after it has stopped stinging. Yesterself is not released yet; there is a waiting list on the site if you want to know when it is.

Starting

Next review you get, write the lines before you write the fix. Eight tags, five fields, ninety seconds. Put a reminder three months out to count them, and then genuinely do not look at the file before then. Reading it weekly turns it back into the thing you were trying to escape: a running tally of how the last review felt.

Common questions

How long before the log is worth reading?

Give it three months, or about sixty comments, whichever comes first. Below that you are reading noise and will mistake one bad week for a pattern.

What do I log when a comment is just wrong?

Log it anyway with a tag like disagreed. A pile of those against one reviewer is itself a finding, and a pile of them against everyone is a finding about you.

Should I show this log to my manager?

Only the summary, and only if you want to. The raw log is for you, and it stays honest exactly as long as nobody else grades it.

Does this work for design or writing critique?

Yes. The mechanic is a tag plus a short quote, so any stream of review comments works the same way.

Is one line per comment really enough?

It is enough to count, which is the whole point. Anything longer and you will stop logging by week two.