Reading code you could not write

You cannot write this code. You still have to review it.

That sounds impossible, and it is not, because the mistakes that cost money are almost never subtle syntax problems. They are the wrong idea, written clearly. A wrong idea is visible to anyone willing to read slowly.

Four techniques, in the order you use them.

1. Read the names

Programming languages are punctuation wrapped around English words. Skip the punctuation on your first pass and read the words.

function saveLink(url) {
  const links = loadLinks();
  links.push(url);
  localStorage.setItem("readlist", JSON.stringify(links));
  render(links);
}

Without knowing any JavaScript: save a link — load the existing links, add this one, store them under the name “readlist”, draw them on screen. That is the whole function, and you just reviewed it.

Now you can ask real questions. What if the same link is added twice? What if the url is empty? Neither is answered here, and you did not need to read a single symbol to notice.

2. Follow one piece of data

Pick one thing a user does and trace it all the way through. For Readlist: pasting a link.

• Where does the text arrive from the box?
• What is done to it before it is stored — trimmed, checked, changed?
• Where is it stored?
• How does it come back out and reach the screen?

Four questions, and the answers are usually four small pieces of code. What you are looking for is a missing step: nothing checks whether it is empty, nothing prevents duplicates, nothing handles the case where storage is full.

This is the single most effective review technique for a beginner, because it follows your mental model of the app rather than the code’s structure.

3. Read the diff, not the file

A diff is the list of what changed: lines removed, lines added, nothing else. Most tools show you one; if yours does not, ask.

Show me a diff of what you just changed.

Read the diff because the code that was already working is not the new risk. The change is.

Three things to look at, in order:

• Which files changed. Anything unexpected here is a question, immediately.
• What was deleted. Additions are usually the feature. Deletions are where things quietly stop working — a check removed “because it was redundant”, a case that no longer exists.
• What was added outside the thing you asked for.

4. Make it explain itself

You are allowed to ask. Endlessly. It never gets impatient.

Explain what this function does, line by line, to someone
who has never programmed.

What happens if the text box is empty when I click Save?

What did you change in this pass, and why did each change
need to happen?

The last one is the most useful question in this lesson. It forces the reasoning into the open, and reasoning is much easier to judge than code. “I also refactored the render function while I was in there” is a sentence you can push back on.

The catch: an explanation describes what the agent intended. If it wrote a bug, it will explain the code as though the bug is not there — because from its perspective, that is what the code says.

So explanations narrow things down. Running the code decides.

How long this should take

For a small change: two minutes. Which files, what was deleted, does anything look unrelated, run it.

For something touching data, money, accounts or deletion: slower, plus the checklist in lesson three of this level.

You are not trying to reach an engineer’s confidence. You are trying to catch the obviously wrong, which is the category most expensive mistakes fall into.

Try it yourself

A five-line diff with a bug in it. You do not need the language to find it.