Learn

Your code review round is next week, and you have only practised writing code

1 November 2026 · A practice plan for the week

The invitation says the next round is a code review: here is a pull request, tell us what you think. You have spent months writing solutions from a blank file, and almost no time reading someone else's change against a clock. Those are different skills, and a week is enough to practise the second one on purpose.

The weakness

Most of us review code at work with context: we know the caller, the ticket and the author. In the round you get none of that. The usual failure is not missing every bug. It is commenting on naming and formatting for ten minutes, then finding the defect that hurts someone with two minutes left and no time to say why it matters.

One interviewer who runs this round in Java writes that they watch which problem catches the candidate's eye first and how they rank what they found. So the week below trains three habits in order: read for behaviour before style, find the smallest input that proves a defect, and state its severity in one sentence.

What goes wrong, on one small diff

An original example. A refund helper is tidied up in a pull request:

# before
def refund_amount(order, requested=None):
    if requested is None:
        requested = order.paid
    return min(requested, order.paid)

# after
def refund_amount(order, requested=None):
    requested = requested or order.paid
    return min(requested, order.paid)

The new line reads as a harmless shortening, and on most inputs it is. Call it with no amount: both versions refund the full payment. Call it with requested=30 on an order that paid 100: both return 30.

Now call it with requested=0. The old version returns 0. The new one treats 0 as missing, because 0 or 100 is 100, and refunds the whole order. The same happens with Decimal("0"), which is also falsy. The diff changed what a zero means, and nothing in the change says so.

What to say out loud

Lead with the defect, the input and who is hurt, before any style comment: "The change I'd block is the or on the first line. With a requested amount of zero, the old code refunds nothing and the new code refunds the full payment, because zero is falsy. That is money leaving the business on a request for none."

Then show you can weigh it rather than just raise it: "How serious it is depends on whether any caller passes zero. I'd check that first. If nobody does today, I'd still ask for is None back and a test for zero, because the next caller won't know." Style comments come after, and you can say they are minor.

The exercise

Seven days, starting tomorrow. Each day has one check, and you write the result down in one line.

1. Monday: the baseline. Take a small diff from your own history, about twenty changed lines, that you have not looked at for a month. Give yourself ten minutes and write every comment you would leave. Check: how many of your comments are about behaviour, and how many about style?
2. Tuesday: behaviour first. Take a second diff. For each changed line, write one sentence on what it now does differently for some input. Only then allow yourself style notes. Check: did you find a behaviour change you would have missed on Monday?
3. Wednesday: the smallest input. For every behaviour change you found so far, write the smallest input that shows it: zero, an empty list, None, a negative, a duplicate. Check: could you name an input for each, or were some of them only a feeling?
4. Thursday: severity in one sentence. For each defect, finish the sentence "this hurts ___ when ___". Rank them. Check: is the top of the list the one you noticed first on Monday?
5. Friday: say it aloud. Take a new diff, set a timer for fifteen minutes, and review it aloud while recording yourself on your phone. Open with the worst defect, its input and who it hurts. Check: how many seconds passed before you said the first defect, and was it the worst one?
6. Saturday: a diff in the other language. If you work in Python, take a Java change, or the reverse, so you cannot lean on habits. Same fifteen minutes, aloud. Check: did your opening still follow defect, input, effect?
7. Sunday: the review. Read your six one-line results. Write down the kind of defect you missed most often, and the input that finally exposed it. Check: put that input first on your list for the next diff you read.

Where this fits in Gadfly

Gadfly has four rooms: algorithms, system design, behavioral and code review. The code review room takes a class of your own, a connected GitHub repository or a project from the catalog, and reviews it together with the transcript that produced it. Code is not executed in that room, so the input that proves a defect has to come from your reasoning, which is the habit this week trains. Code review is part of a session pack. You work in Java or Python, and the tutor speaks English. The plan above works with your own old diffs and a timer instead.