---
title: "Code Review: Reading a Change You Did Not Write"
description: "Review reads a diff and asks whether it does what was intended, whether it breaks anything nearby, and whether the next person will understand it. The skill is separating the change that has to happen"
canonical: https://lightmysky.com/learn/computing/code-review-reading-a-change-you-did-not-write-mt_Hhe1Ou709s
source: https://lightmysky.com/learn/computing/code-review-reading-a-change-you-did-not-write-mt_Hhe1Ou709s.md
retrieved: 2026-09-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Code Review: Reading a Change You Did Not Write

Review reads a diff and asks whether it does what was intended, whether it breaks anything nearby, and whether the next person will understand it. The skill is separating the change that has to happen from the taste that does not.

Subject: Computing · Area: Software Engineering · Ages 18 to 20
Page: https://lightmysky.com/learn/computing/code-review-reading-a-change-you-did-not-write-mt_Hhe1Ou709s

## Ready when they can

- Review a small change and separate correctness comments from preference comments
- Ask a question about a change instead of asserting what it should have been
- Spot a change that is right in itself but breaks a caller elsewhere

## Lesson: Reading someone else's diff

Review reads a diff and asks three questions. Does the change do what was intended. Does it break anything nearby. Will the next person understand it.

**Example.** This crashes on empty input is a correctness comment. It names behaviour that must be fixed. I would rename this variable is a preference comment. It names taste that the author may keep.

Ask a question instead of asserting what the change should have been. What happens when the input is empty invites checking. Then look past the changed lines, because a change can be right in itself yet break a caller elsewhere.

**Tip.** On a twenty-line change, leave two comments that still matter if the author disagrees about style. Name the broken case or the confused caller. Skip the naming taste.

**Recap.** Judge the behaviour, ask instead of command, and check the callers the diff never shows.

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Debugging as a Method: Reproduce, Isolate, Fix](https://lightmysky.com/learn/computing/debugging-as-a-method-reproduce-isolate-fix-mt_2JGE4ICRf6)
- [Branching, Merging and Resolving a Conflict](https://lightmysky.com/learn/computing/branching-merging-and-resolving-a-conflict-mt_l3vFbU7L3E)
- [Requirements: Turning a Wish into a Testable Statement](https://lightmysky.com/learn/computing/requirements-turning-a-wish-into-a-testable-statement-mt_TFb-YNpvT1)