Pull Requests & Code Review as a Practice
Before new code joins the shared main line, a teammate looks it over. The change is proposed as a pull request (PR) — a packaged-up set of changes others can read, comment on, and approve. The act of examining it is code review, and it's one of the highest-leverage quality practices a team has.
The idea is simple but powerful: nothing important goes into the main codebase without a second pair of eyes. That single habit catches bugs, spreads knowledge, and keeps the codebase coherent.
A familiar parallel: having a colleague read an important email before you send it to the whole company. A few minutes of someone else's attention catches the mistakes you can't see in your own work.
The Pull Request
A pull request says, in effect: "here's my change on a branch — please review it before it merges into main." It bundles the commits, shows exactly what's different, and gives the team a place to discuss it line by line. Nothing merges until the PR is approved, so the PR is the gate every change passes through on its way into the shared code.
What Reviewers Look For
Good review is about more than typos. Reviewers check that the code is correct (does it actually do the right thing?), clear (can the next person read it?), tested (is it covered so it won't silently break later?), and well-designed (does it fit the system sensibly?). Style matters least — and is increasingly handled by the automated guards from Chapter 7 — so humans can focus on the things only a thinking reader can catch.
Review as Culture
The best teams treat review as collaboration, not gatekeeping. A review spreads knowledge (now two people understand that code), mentors newer developers, and builds shared ownership of the whole codebase. It works best when it's about the code, not the person — kind, specific, and curious rather than combative. Review is a place to learn together, not a test to pass or fail.
Keeping PRs Small
One practical rule decides whether review actually works: keep pull requests small. A small, focused change gets a real, careful review; a giant one gets a tired rubber-stamp, because no one can hold a thousand lines in their head. Small PRs are reviewed properly, merged faster, and easier to undo if something's wrong. "Make the PR smaller" is some of the most common — and most useful — review advice there is.
Lena opens a pull request for the reminders feature. Marcus reviews it and spots an edge case she missed: what if the chosen reminder time is in the past? They discuss it right in the PR, she fixes it, and only then does it merge. The bug never reached users — and now two people, not one, understand how reminders work. That's code review doing both of its jobs at once.
- "Code review is mostly about catching typos and style." Those matter least and are often automated. Review is really about correctness, design, and shared understanding — what only a thinking human can judge.
- "Review slows the team down, so skip it when busy." It's far cheaper than fixing bugs that escape to production. The few minutes of review save hours of debugging later — the cost-of-change curve again.
- "The author should defend their code in review." Review is collaborative, not adversarial. It's two people improving the code together, not one prosecuting the other's work.
- Code review catches bugs early — on the cheap side of the cost-of-change curve — before they ever reach a user.
- It spreads knowledge so no one is a single point of failure: every reviewed change is understood by at least two people.
- "Open a PR", "request review", "LGTM" (looks good to me) are everyday team rituals — this is the practice behind all of them.
Knowledge Check
What is a pull request?
- A packaged change proposed for review before it merges into main
- A report asking the team to go and fix a particular bug found in the code
- A request from users asking for a new feature to be built
- The act of deploying finished code out to all of the users
What do reviewers mainly look for in code review?
- Correctness, clarity, tests, and design — not mainly style or typos
- Mainly the spacing, the indentation, and the overall formatting of the code
- How quickly the author was able to type out the change
- The total number of lines the author managed to write
Why is keeping pull requests small important?
- Small changes get a real review; huge ones get a tired rubber-stamp
- Because small pull requests mean the finished product has fewer features overall
- Because smaller pull requests make the finished app run faster
- Because small pull requests can skip the review step entirely
What does the topic mean by "review as culture, not gatekeeping"?
- It's collaboration that spreads knowledge, about the code not the person
- It's a strict test that the author has to pass before they can ever be trusted
- It's the reviewer's chance to prove the author's code is bad
- It's only for senior developers to judge the junior ones
Besides catching bugs, what is a major benefit of code review?
- It spreads knowledge, so at least two people understand each change
- It makes the finished program run measurably faster for all of its users
- It removes the need to ever write any tests for the code
- It deploys the reviewed code straight out to all the users
You got correct