5 exercises — master the advanced informal language of pull request culture: rubber duck review, gold plating, scope creep, yak shaving, and premature optimisation. Essential vocabulary for developers on English-speaking teams.
PR review expressions covered in this set
rubber duck review — explaining code to yourself to catch your own bugs
gold plating — adding unnecessary features beyond what was asked
scope creep in a PR — a PR that grows beyond its original purpose
yak shaving — a chain of prerequisite tasks leading far from the original goal
premature optimisation — optimising before proving a performance problem exists
0 / 5 completed
1 / 5
A senior engineer reviews your PR and says: "This is classic rubber duck reviewing — you clearly explained your logic in the description and caught the bug yourself before asking for my input." What does "rubber duck review" (or rubber duck debugging) mean in this context?
Rubber duck debugging / rubber duck review = explaining your code out loud to spot your own bugs:
The classic "rubber duck" technique: a programmer explains their code line by line to an inanimate rubber duck. The act of articulating the problem forces the brain to slow down, switch from writing mode to explaining mode, and notice inconsistencies that seemed invisible before.
In PR culture this appears as:
Writing a detailed PR description before requesting review — often reveals issues the author hadn't noticed
Self-reviewing your diff in the GitHub UI before tagging reviewers
Adding inline comments explaining why you made a decision — which sometimes makes you realise the decision was wrong
Why it matters:
Reduces reviewer load — the author catches obvious problems first
Forces clearer thinking about the change being made
The PR description doubles as documentation for future readers
Classic quote attributed to the technique: "I've been programming for 30 years and the rubber duck still finds bugs my colleagues miss."
In professional teams, a well-written PR description is considered a courtesy to reviewers — and writing it often makes you your own best first reviewer.
2 / 5
A reviewer comments on your PR: "This is gold plating — the ticket asked for a simple toggle, and you've built a full configuration system with twelve options." What does "gold plating" mean?
Gold plating = adding unnecessary features or over-engineering beyond what was asked:
The term comes from project management: "gold plating" is adding features that weren't requested and aren't needed — making something more elaborate than required, like covering a simple bolt in gold. It looks impressive but adds cost and complexity with no clear benefit.
In software development, gold plating looks like:
Building a full plugin system when the requirement was a single hardcoded value
Adding extensive configuration options to something the user will never configure
Refactoring unrelated code while in a PR for a bug fix
Implementing three edge cases that haven't been asked for and probably won't occur
Why it's a problem:
Increases code review burden — more code, more potential bugs
Adds maintenance surface area without validated user need
Delays shipping the actual requirement
The extra features often get built to different (lower) standards because they weren't the focus
Related terms:
YAGNI — You Ain't Gonna Need It — the XP principle arguing against building for hypothetical future needs
scope creep — when a task grows beyond its original boundaries
over-engineering — building a complex solution for a simple problem
The antidote to gold plating is ruthless scope discipline: ship what was asked, then iterate if users actually need more.
3 / 5
During a sprint, a PR that started as "fix the login button colour" now includes a refactored authentication flow, a new user settings page, and three API changes. A senior engineer calls this "scope creep in a PR". What does this expression describe?
Scope creep in a PR = a pull request that has grown far beyond its original, stated purpose:
"Scope creep" is a classic project management term describing a project expanding beyond its original goals, usually through gradual, unplanned additions. In a PR context, it happens when:
The author notices related improvements while implementing the main change
"While I'm here" thinking takes over: "I'll just fix this other thing too"
The PR ticket wasn't scoped tightly enough from the start
Why large, scope-creeping PRs are problematic:
Harder to review thoroughly — reviewers face fatigue on large diffs
More risk per merge — more things can go wrong
Harder to roll back if something breaks — the fix and the unrelated changes are coupled
Blocks other work — the PR sits in review longer
Best practice — the single responsibility principle for PRs:
Each PR should do one thing and do it completely
If you find an improvement while working, open a separate PR or create a follow-up ticket
A good PR description fits in 2–3 sentences: "This PR does X. It does not do Y."
Common team rules to prevent scope creep:
PRs over 400 lines changed get flagged for splitting
PR title must match every file changed — if it doesn't, something is out of scope
Unrelated refactors must be separate PRs
4 / 5
A team lead tells a junior developer: "You're doing yak shaving — we asked you to add a tooltip, and now you're rewriting the entire component library because the tooltip doesn't fit the design system." What is yak shaving?
Yak shaving = a chain of prerequisite tasks that leads you further and further from your original goal:
The term was popularised by Carlin Vieri at MIT and made famous by Seth Godin. The archetypal story:
"I want to wax my car → I need a bucket → the bucket has a hole → I need to fix it with wood → I need to cut wood → my saw needs sharpening → I need to buy a new saw → the store is far → I need the car but it's not waxed yet…" and at some point you find yourself in the mountains shaving a yak to get the wool to make the rope to fix the bucket.
In code review and development:
You need to add a button → the button component needs updating → the design system needs a new token → the token system needs refactoring → now you're rewriting the build pipeline
Each step seems like a legitimate prerequisite, but collectively they lead you miles from the original task
How to recognise yak shaving in a PR:
The PR description can no longer be summarised in one sentence
The files changed have no obvious connection to each other
The author says "I had to do X before I could do Y before I could do Z, which is the actual task"
The fix: Stop at the first yak. Create a ticket for the prerequisite problem. Solve the original task with a workaround if needed. Ship first, then fix the underlying issues in focused PRs.
5 / 5
A reviewer leaves a comment: "This is premature optimisation — you've spent three days micro-optimising a function that runs once per day and takes 12 milliseconds. Let's ship the readable version first." What does premature optimisation mean?
Premature optimisation = optimising for performance before you have evidence a performance problem exists:
The phrase comes from Donald Knuth's famous 1974 quote:
"Premature optimisation is the root of all evil (or at least most of it) in programming."
Knuth's point: most code doesn't need to be fast — it needs to be correct and readable. When developers optimise before profiling, they typically:
Make code harder to read and maintain
Optimise the wrong parts (the parts that feel slow, not the parts that actually are)
Introduce bugs in the name of performance
Spend days saving microseconds that will never be noticed by users
The correct workflow:
Make it work — write readable, correct code
Make it right — test it, handle edge cases
Make it fast — only if profiling shows a real bottleneck
In PR review context, this means:
Rejecting complex bit manipulation when a simple loop is readable and fast enough
Questioning caching layers added "just in case" without a measured problem
Preferring clear variable names over micro-optimised one-liners
Related concepts:
YAGNI — You Ain't Gonna Need It (related: don't build for hypothetical needs)