Code review: taking part without taking offence

What it is

Before changes reach the shared codebase, someone else reads them and leaves comments. The author revises, comments are repeated or resolved, and the changes are accepted.

Why it exists

Mistakes are caught before they ship. Another pair of eyes sees what you've stopped noticing.

Knowledge spreads through the team. Everyone learns a little about neighbouring parts.

Beginners grow fastest. For someone without experience, regular review of their code is the most powerful accelerator there is. Six months with review beats two years without.

Which is why it's worth asking at interview whether the company does code review: a place without it will hold you back a year.

Receiving comments

Don't argue on first reaction. The first feeling is nearly always "but I did it right". Let it pass, then read on the substance.

Separate the code from yourself. A comment on code isn't a judgement on you as a person. Hard for the first months, easy afterwards.

Ask when it isn't clear. "I don't follow this comment, could you explain?" is an ordinary sentence, not an admission of weakness.

If you disagree, explain. Calmly and factually: "I did it this way because of that. If there's a reason to change, I will." A reasoned objection earns respect.

Reply to every comment. Fixed, or explained why not. Silently ignored comments irritate most of all.

Giving comments

About the code, not the person. Not "you didn't think", but "this will crash on an empty list".

Explain why. Not "redo this", but "this query runs a hundred times inside the loop; better to move it out".

Separate substance from taste. If it's a matter of habit, say so: "not required, but I'd name it differently".

Praise what's good. One line — "nice extraction into a separate function" — holds a person better than ten comments break them.

Don't rewrite it for them. Your job is to point at the problem, not to do the work.

What to look at as a beginner

It feels as though a beginner has nothing to say about someone else's code. Not so. You can:

• Ask what's unclear. If you can't follow it, the code probably does need explaining.
• Check the scenarios. What happens on empty input, with no data, on a second click.
• Notice divergence from the task description.

A beginner's question often catches a real problem precisely because they don't know "how it's usually done" and look with fresh eyes.

Where to practise before employment

In open source: submit a change and receive comments. And in shared project work — there you both receive review and give it.

It's a skill that shows immediately on a first job: someone used to review stays calm, while someone meeting it for the first time takes offence and slows the team.