In 30 seconds
- A second pair of eyes catches bugs and unclear design.
- Reviews spread knowledge across the team.
- Small changes and fast turnaround make reviews work.
What to look for
- Does it do what the story needs?
- Is it easy to understand and change?
- Are there tests, and do they check the right things?
- Any security or performance risks?
Leave formatting to automated tools.
Keeping reviews fast
- Keep pull requests small: a few hundred lines at most
- Agree a review turnaround in working agreements, such as within a day
- Treat pending reviews as work in progress subject to WIP limits
Reviews vs pairing
Pair programming reviews continuously as code is written. Many teams use pairing for complex work and asynchronous reviews for the rest.
Myth vs reality
Myth · Reviews are for catching bugs.
Reality · Sharing knowledge and design is just as important.
Myth · Senior developers should review everything.
Reality · Everyone reviews; it spreads knowledge both ways.
Myth · Big reviews are more thorough.
Reality · Large changes get skimmed; small ones get real attention.
The AI angle
AI-written code needs closer review, not less: the reviewer didn't write it and the author may not fully understand it. Use AI as a first pass, with humans deciding.
FAQ
How long should a review take?
Most should take under an hour.
How do we give feedback kindly?
Comment on code, not people, and explain the why.
Should reviews block merging?
Usually yes, with fast turnaround so they don't stall flow.