Code Reviews & Shipping

No matter how good an engineer is, nobody ships straight to customers on their own say-so. Before code reaches users, at least one other person looks it over. The vehicle for that second pair of eyes is a pull request (PR) — a proposal that says, in effect, “here’s a change I’d like to merge into our main code; please review it.” On the PR, teammates read the change, leave comments, ask questions, request tweaks, and eventually approve. Alongside the humans, automated CI checks run in the background, so whole categories of bugs get caught before a person even starts reading.

The pull request flow, step by step

Follow a change from finished work to live feature and the diagram above comes to life.

First you open a PR from your branch. This gathers up all your commits into one reviewable bundle and gives your teammates a place to discuss it. A good PR comes with a short description: what changed, and why.

Next comes review. One or more colleagues read the code and respond. They might approve it outright, or they might request changes — leaving comments like “this could break if the list is empty” or “can we rename this so it’s clearer?” You make the fixes, push new commits, and the conversation continues until everyone’s satisfied.

Meanwhile, CI tests run automatically every time you push. If a test fails, the PR is flagged before a human wastes time reviewing broken code. Once reviewers have approved and the tests are green, the change is merged into main. From there, CD can take over and deploy it — release it to production — often with no manual steps at all.

What a good review actually checks

A common misconception is that review is about catching typos or enforcing personal taste. It isn’t. A good review weighs three things: correctness (does it do what it claims, including the awkward edge cases?), clarity (will someone understand this code in six months?), and risk (what could this break, and how would we recover?). Style preferences — tabs versus spaces, where the brackets go — are mostly handled by automated tools precisely so humans can spend their attention on what matters.

Review the code, not the coder. The goal is a better change, not a winner of the argument.

Etiquette, on both sides

Reviews are where engineering teams either build trust or quietly erode it, so the manners matter.

As the author, do your reviewer two favours. Keep the PR small — a focused change is far easier to review well than a sprawling one, and small changes are safer to ship. And explain why you did something, not just what; the reasoning is the part a reviewer can’t reconstruct on their own.

As the reviewer, be specific and be kind. “Consider X because Y” is far more useful than “this is wrong,” because it teaches and offers a path forward. Ask questions rather than issuing verdicts. Remember there’s a colleague on the other end who put real effort in, and that one day the roles will be reversed.

CI/CD: the automation behind it all

You’ll hear CI/CD constantly, so it’s worth unpacking. CI (Continuous Integration) means every change is automatically built and tested the moment it’s pushed, so problems surface immediately instead of piling up. CD (Continuous Delivery, or Deployment) means approved changes are automatically released, rather than batched into a tense, once-a-quarter launch. Together they make releases small, frequent, and low-drama — a ten-line change shipped on a Tuesday afternoon, not a giant release everyone dreads. The payoff is huge: when something does go wrong, a small recent change is quick to find and easy to roll back.

Spot it: the PR flow

Read each situation and decide for yourself, then tap a card to flip it and check your answer.

Sort the review signals

Drag each item into the bucket it belongs to — or tap an item, then tap a bucket. Hit Check placement when you’re done.

How to use it

Even if you never open a PR yourself, this vocabulary makes engineering work legible. “It’s in review” means the code is finished but waiting on human approval — a normal, healthy stage, not a stall. “CI is failing” means an automated check caught a problem and the change can’t ship yet. “We deployed it” means it’s live for customers. And if you’re ever asked to weigh in on a PR or you’re watching a review unfold, you’ll know the bar is correctness, clarity, and risk — and that the kindest, most effective feedback is specific, curious, and aimed squarely at the code rather than the person who wrote it.