Code Review: Why Good Programmers Let Other People Read Their Code

To put it simply, a code review is what happens when another programmer reads your new code carefully before it joins the rest of the program. Not to grade you. Not to catch you out. Just to check the work with fresh eyes while fixing a mistake is still cheap.

You know this moment from your own week. You write an important email, read it over four or five times, and feel sure it is clean. Then a friend glances at it for ten seconds and says, "You wrote the wrong date." Ten seconds. The date was wrong from the first draft, and you read straight past it every single time, because your eyes kept seeing the date you meant to write, not the one on the screen.

Code is exactly the same, only the stakes are higher. When you write code, you know what you intended, and that knowledge blinds you. You read your intention instead of your lines. A reviewer has no intention to be blinded by — they only have the lines. That is the whole trick, and it works because of a simple fact about people: your own eyes are the worst proofreaders you own.

A reviewer is not reading to judge you, they are reading to help the code

Beginners often imagine a reviewer sitting there with a red pen, hunting for reasons to say no. In a healthy team it looks very different. The reviewer is asking a short list of honest questions about the change in front of them:

• Does this code actually do what the author says it does?
• What happens with the strange inputs — empty, huge, missing, or just plain weird?
• Can the next person read this and understand it without asking the author?
• Are the names honest? Does a thing called total contain a total?
• Is there a test that would catch this if it broke later?
• Is any part more complicated than the problem deserves?

Notice what is not on that list: "Is this how I would have written it?" Good reviewers learn to let that question go. There are ten good ways to write most code. The reviewer's job is to check that this way is correct, clear, and safe — not that it matches their personal taste.

One review, from start to finish

So how does it actually run, day to day? Simpler than most people expect:

• You finish a small piece of work and open a pull request — your change, presented to the team with a short explanation of what it does and why
• A teammate reads the change in context, looking at the new lines beside the old ones, and asks questions or leaves comments where something is unclear or risky
• You reply, adjust what needs adjusting, and push the improved version
• When the reviewer is satisfied the change is safe and readable, they approve it, and the code joins the main program

That is all. No ceremony, no exam hall. Most reviews in a working team are a handful of comments on a small change, done within the day. The habit looks almost too small to matter — until you remember it happens on every change, every week, for years. Small checks, repeated forever, are how big programs stay trustworthy.

Comments are about the code, never about the coder

This is the part nobody teaches and everybody needs. Reviews go wrong when people forget which side of the screen the comment belongs to.

If you are receiving comments, try to hold on to one thought: the reviewer is describing the code, not scoring you as a person. "This function does three things at once" is a sentence about a function. It is not a sentence about your worth. The fastest way to grow as a programmer is to treat every comment as free information — sometimes the comment is wrong, and you explain why, calmly, and that is fine too. Defending your code line by line as if it were your honour helps nobody, least of all you.

If you are giving comments, the same rule from the other side. Ask instead of ordering: "What happens here if the list is empty?" teaches more than "This is wrong." Point at the code, suggest a direction, and say plainly when something is a small taste matter rather than a real problem. And when the code is good, say that too. A review that only ever lists faults trains people to dread reviews.

Small rules that make the whole thing painless

Over time, good teams settle into a few habits that keep reviews quick and kind:

• Keep changes small. A reviewer can hold a hundred changed lines in their head. A thousand is not a review, it is a second job — and big changes hide big mistakes.
• Explain the why in the description. What problem does this solve? The reviewer should not have to guess your reasons.
• Review quickly. A teammate waiting a full day for your eyes is a teammate not working. Same day is polite; within the hour is kind.
• Let machines handle the boring fights. Formatting and spacing can be checked by tools, so save human attention for questions of logic and clarity.
• Separate real problems from small preferences, and label them honestly, so the author knows what must change and what is optional.

None of these need talent. They are manners, and manners scale.

A team that reviews well ends up with more than safer code. Knowledge spreads — nobody is the only person who understands a corner of the system. Juniors absorb the habits of seniors just by reading their comments. And the code slowly becomes something the whole team owns, instead of a pile of private territories everyone is afraid to touch.

So let people read your code. Early, often, while the mistakes are still small and cheap. The wrong date in the email costs you an apology. The wrong line in the code can cost a whole weekend. Fresh eyes are the cheapest safety tool a programmer will ever have.

Takeaways:

• A review is fresh eyes on your code before it joins the program — cheap now, expensive later
• Reviewers check correctness, edge cases, and clarity, not whether the code matches their taste
• Comments describe the code, never the coder — receive them as information, give them as questions
• Small changes, a clear why, and a fast reply keep reviews painless for everyone

References and further reading

• Code review — Wikipedia
• Peer review — Wikipedia
• Pull request — Wikipedia
• Google's Code Review Developer Guide

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org