A proposed change is opened as a pull request and read by another engineer before it's allowed into the product.
Why it exists
Letting anyone change shared production code directly means mistakes ship unseen, so changes need a checkpoint before they land. Pull requests and code review exist so a proposed change is shown, discussed, and approved by someone else before it merges, catching bugs and spreading knowledge across the team.
How it actually works
Rather than putting changes straight into the shared code, an engineer opens a pull request: "here's my change, please review." Another engineer reads it, comments, asks for fixes, and approves. Only then does it merge in.
This catches bugs, spreads knowledge, and keeps quality consistent. It's a deliberate gate: no change enters unseen by a second person.
A senior PM walks you through it
A junior PM, stuck
My free-delivery feature has said in review for two days and my lead keeps asking me when it ships. I finally opened the PR to see what is holding it up, and between the diff and the comment thread I could not tell what is actually blocking it or whose move it is.
In review is not one status, it is a small process with a state you can read, and the state tells you exactly who owes the next move. You do not need to understand the code to find the blocker, you need to read the review conversation. This is the actual PR. Read the state and the one comment, then take the steps with me.
PR: Add free-delivery threshold above 500 taka
PR
Author: Rafi State: changes requested
Diff: 12 lines in checkout.ts
+ if (subtotal > 500) deliveryFee = 0 // free delivery above 500 taka
Review thread
reviewer If the cart has a coupon, coupon.code can be null here and this line crashes. Add a null check before you read it. Requesting changes.
Rafi Pushed a commit: guard against a null coupon code before the delivery check.
reviewer Looks good now. Approved.
Click a step to see the lines it points at.
Mistakes I've seen
Reading in review as almost done. It is a real status between code-complete and shipped, and a changes-requested PR can sit for days with the author still owing a fix.
Not knowing changes requested puts the ball back with the author. Chase the reviewer for a merge that is waiting on the author's commit and you nudge the wrong person and lose another day.
Treating review time as bureaucracy slowing you down. That one comment caught a null coupon code that would have crashed checkout, which is the bug tax review quietly pays down.
Asking for a ship date without opening the PR. The state and the open comments are right there, and reading them beats guessing or relaying a vague soon to your lead.
Tell your lead: "It is in changes requested. The reviewer asked for a null check on coupon codes, so it is waiting on Rafi's fix commit, not on the reviewer. I will confirm when that lands and it can merge." You read a PR's state to find the blocker and whose move it is, which is how in review stops being a mystery.
Where a PM meets this
Review is why shipping isn't instant, and why it's more reliable; it's a quality investment, not bureaucracy.
"It's in review" is a real status between done and shipped; knowing it exists sets accurate expectations on timelines.
Hear it in a meeting
"It's code-complete, just waiting on review before it can merge."