{TOTAL} exercises — select the Slack message that uses each expression naturally and correctly. Learn not just what these idioms mean, but how real developers actually use them.
0 / 5 completed
1 / 5
You are writing a Slack message to your team after a long troubleshooting session. You eventually solved the issue by re-reading the documentation — not by any complex debugging. Which message naturally and correctly uses the expression "rubber duck debugging"?
Option B uses "rubber duck debugging" correctly and naturally. The expression means explaining a problem to yourself (or to an inanimate object) out loud to trigger your own epiphany. In this context, the developer spent time talking through the problem and ultimately found the obvious answer. The casual tone and self-deprecating "Classic." at the end are perfect for Slack.
Option A is wrong — "rubber duck debugging tool" makes no sense; it is not a software tool, it is a cognitive technique. Option C uses "debug the rubber duck" — reversing the idiom incorrectly. Option D uses it as an adjective for a process — "rubber duck our deployment" — which is not how the expression is used.
Real Slack usage:"Just rubber-ducked my way to a solution — turns out I was appending instead of prepending. 🦆"
2 / 5
In a sprint planning meeting, your team is discussing which tasks to tackle this sprint. The product manager wants to prioritise some quick improvements that will have immediate visible impact. Which sentence naturally uses"low-hanging fruit"?
Option B is the natural, professional use of "low-hanging fruit". The idiom describes easy wins — tasks with low effort but high visibility or impact. Option B correctly: (1) uses "pick the low-hanging fruit" (the standard verb phrase — you pick fruit), (2) immediately provides concrete examples, and (3) quantifies with "1–2 point tickets and high visibility", which mirrors how a real PM would use this expression.
Option A says "harvest the low-hanging fruit in the backlog" — "harvest" can work but sounds odd; more critically, "all tickets created before Q3" is not particularly low-effort. Option C pluralises it as "low-hanging fruits" — this is a minor error; as a fixed idiom, "low-hanging fruit" is typically uncountable/singular as a mass noun. Option D turns it into a verb ("low-hang-fruit") — this is not a real usage.
3 / 5
A senior developer asks why you spent two days on a configuration problem before realising it was caused by a missing environment variable. You want to describe the experience using "yak shaving". Which Slack message is correct?
Option B uses "yak shaving" correctly and with exactly the right structure. Yak shaving describes a chain of (seemingly necessary) prerequisite tasks that pull you away from the original goal. The hallmark pattern is: "I needed X, but to get X I had to do Y, and for Y I needed Z…" — and Option B demonstrates this perfectly.
Option A uses "yak shave the production server" as if it were a transitive verb with a direct object — you do not "yak shave" a specific thing; the expression describes the act of being drawn into a chain of tasks. Option C pluralises it as "yak shavings" — the expression is used as a mass noun or gerund phrase, not as a countable plural. Option D suggests a "yak shaving session" as a planned activity — this misunderstands the idiom; yak shaving is always accidental, not intentional.
Correct Slack usage:"I went full yak shaving this morning — just wanted to run the tests, ended up half-rewriting the CI config. 🐃"
4 / 5
Your team's sprint review keeps getting derailed by detailed discussions about the colour of buttons, icon sizes, and tab label wording — rather than the architectural decisions that need sign-off. How would you use "bikeshedding" to describe this to a colleague?
Option A correctly uses "bikeshedding" as a gerund (noun form of the verb "to bikeshed") in a natural professional context. The canonical structure is "stop bikeshedding on [trivial detail]" — this is exactly how engineers and PMs use the term in meetings and Slack. It names the problem clearly and redirects attention.
The origin: Parkinson's Law of Triviality — a nuclear committee spends 2 minutes approving a reactor design and 45 minutes debating the bike shed colour, because everyone has an opinion on a bike shed but few can evaluate a reactor. Option B treats "bikeshed" as a concrete object rather than the idiom — "the bikeshed in our sprint review is the button colour" would confuse listeners. Option C says "bikeshare" — this is a completely different word (a bike-sharing scheme). Option D makes it sound like "bikeshedding work" is a workload category — the expression refers to the behaviour of over-discussing trivialities, not a type of task.
Real usage:"Let's not bikeshed the variable naming convention for an hour again — @team please vote async and we'll go with majority."
5 / 5
Your team is discussing a new initiative to build a feature that already exists in a widely-used open source library. You want to advise against it using the expression "reinventing the wheel". Which response would a senior engineer most likely write in Slack?
Option A is the correct, natural, and persuasive use of "reinventing the wheel". It: (1) states the concern clearly using the idiom, (2) names concrete existing alternatives (making it actionable rather than just a complaint), and (3) proposes a sensible next step. This is exactly how a senior engineer communicates in a team discussion.
"Re-inventing the wheel" (with or without the hyphen) means creating something from scratch that already exists without meaningful improvement — it implies wasted effort. Option B reverses the meaning — using a library instead of building your own is the opposite of reinventing the wheel. Option C uses it for a process/management action — the idiom is almost exclusively used for technical or product decisions, not administrative actions. Option D uses "reinvented wheels that need to be spun up" — this mixes metaphors in a confusing way; "spin up" means to start a service/process, not to re-examine an implementation.
Also correct:"Before we build this from scratch: aren't we reinventing the wheel? lodash already does this in one line."