5 exercises — decode the informal language of code review: LGTM, nit, ship it, drive-by review, and bike-shedding. Essential vocabulary for developers working on teams that review code in English.
Code review culture expressions covered in this set
LGTM — Looks Good To Me — informal approval
nit — nitpick — a minor, optional suggestion
Ship it! — enthusiastic approval to merge and deploy
drive-by review — superficial review without full context
bike-shedding — excessive debate on trivial details
0 / 5 completed
1 / 5
A developer writes "LGTM" as a comment on your pull request. What does this mean?
LGTM = Looks Good To Me — an informal approval in code review culture.
When a reviewer writes LGTM, they are saying: "I've reviewed your changes and I approve them." On GitHub, it is often used alongside or instead of the formal "Approve" review status. In many teams, one or two LGTM comments from senior engineers are the green light to merge.
Common usage patterns:
"LGTM!" — simple approval
"LGTM modulo the nit above" — approved, but please fix the minor suggestion first
"LGTM from my side, waiting for @teammate" — partial approval, needs another reviewer
Related approval expressions:
LGTM — Looks Good To Me
ship it 🚢 — enthusiastic approval to deploy
👍 / +1 — agreement (from the old GitHub emoji-only reaction era)
Approved — the formal GitHub review status
LGTM is informal and conversational — avoid using it in external communication or formal code review forms.
2 / 5
A reviewer leaves a comment starting with "nit:" on your PR. What does this mean?
nit = nitpick — a minor, optional suggestion that should not block the PR.
The word "nitpick" comes from the practice of picking nits (lice eggs) from hair — tedious, small, detail-oriented work. In code review, a "nit" is a small style or cosmetic suggestion that the reviewer considers optional:
Examples of nit comments:
nit: I'd name this variable `userCount` instead of `cnt` for clarity
nit: extra blank line here
nit: could use a ternary here, but not a blocker
Why nits matter in code review culture: Labelling a comment as a "nit" is a sign of respect — it tells the author "this is my personal preference, feel free to ignore it." Without the "nit:" prefix, the author doesn't know if a comment is blocking or advisory.
Common code review comment categories:
nit / nitpick — optional, minor style preference
blocking — must fix before merge
suggestion — recommended but not required
question — asking for clarification, not requesting a change
Good reviewers label their comments to reduce ambiguity.
3 / 5
A team member comments "Ship it!" on a pull request that has been reviewed and tested. What does this mean?
"Ship it!" = approve and merge — enthusiastic endorsement to deploy:
"Ship it" in tech culture means "send it out" — release the code to production. As a PR comment, it is an informal but very positive approval: "this looks great, let's get it deployed."
The phrase comes from product culture: "shipping" is the act of releasing software. Teams "ship" features to users. The ethos of shipping quickly is central to agile and startup culture — often contrasted with "analysis paralysis" (endless discussion without decision).
Nautical emoji often accompanies it:
🚢 ship it — classic GitHub reaction
🚀 let's launch — same enthusiasm, space metaphor
Related approval expressions used in PR culture:
"Merge when ready" — approved; you can merge whenever you're confident
"LGTM, ship it" — double approval
"Go for it" — informal green light
Note: in formal processes, "ship it" in comments does not replace a formal GitHub "Approve" review — most teams require the official approve action to unblock the merge button.
4 / 5
A colleague says: "That was a drive-by review — they left five comments but clearly didn't read the context." What does "drive-by review" refer to?
Drive-by review = a quick, superficial review that leaves comments without deep context:
The metaphor comes from "drive-by shooting" — someone who makes a rapid pass, leaves impact, and disappears. In code review, a drive-by reviewer:
Comments on surface-level style issues without reading the broader problem being solved
Asks questions that are answered in the PR description (which they didn't read)
Leaves blocking comments and then disappears — not watching for replies
Reviews individual lines without understanding the architecture or business context
Why it's considered negative: Drive-by reviews add noise without adding value. They block the author with comments that may be irrelevant, and they don't catch the real issues because the reviewer never understood the code deeply.
Good review practices (the opposite):
Read the PR description and linked issue before reviewing code
Understand the intent before suggesting alternatives
Follow up after leaving comments — stay engaged in the discussion
Focus on correctness, security, and architecture before style
5 / 5
During a PR discussion, the team spends 45 minutes debating whether a boolean variable should be named isActive or active, while ignoring a potential security issue in the same PR. This is an example of:
"Bike-shedding"
Bike-shedding = spending excessive time on trivial decisions while ignoring what matters:
The term comes from Parkinson's Law of Triviality, illustrated by C. Northcote Parkinson's example:
A committee approves a nuclear power plant design in minutes — nobody understands it well enough to object
The same committee spends 45 minutes discussing the roof material for a bike shed — everyone has an opinion on something so simple
Why it happens in code review:
Variable names, formatting, and minor style issues are easy for everyone to have opinions on — no expertise required
Architecture, security, and algorithmic correctness require deep understanding — fewer people engage
It feels productive to have a long discussion, even if the outcome is trivial
How to avoid bike-shedding:
Use a linter or formatter to automate style decisions — remove them from human debate
Define a team style guide — variable naming conventions shouldn't be relitigated per PR
Timebox discussions: "If we can't decide in 5 minutes, we default to X"
As a reviewer, consciously ask: "Is this the most important thing to discuss in this PR?"