5 exercises — practise swapping vague quantifiers and hedges for precise technical detail.
0 / 5 completed
1 / 5
Which sentence replaces vague quantification with precise technical detail in a performance report?
"340 requests exceeding the 2-second latency threshold during peak hours" is correct: it replaces vague quantification with an exact count and a defined threshold, giving readers actionable, verifiable information. Option A's "a lot of" is a vague quantifier that provides no measurable scale. Option B's "quite a few" is similarly imprecise and subjective. Option D's "some" is the vaguest option, offering essentially no quantitative information at all.
2 / 5
Which sentence replaces the vague word "stuff" with precise technical terminology in a bug report?
"Fails to validate the CVV field before submitting the payment request" is correct: it names the exact failing component (CVV validation) and the exact point of failure (before submission), which is essential for a bug report to be actionable. Option A's "some stuff broken" identifies neither what is broken nor how. Option B's "stuff going wrong with payments" is similarly vague, naming a general area but no specific defect. Option D's "something is off with...stuff" is the vaguest of all, providing no diagnostic value whatsoever.
3 / 5
Which sentence uses precise technical language instead of the vague hedge "kind of" when describing a system's reliability?
"Maintained 99.95% uptime over the past 30 days" is correct: it states a precise, measurable metric with a clear time frame, which is what reliability reporting requires. Option A's "kind of stable" is a vague hedge that gives no measurable indication of actual stability. Option B's "sort of working better" is similarly imprecise and subjective, with no baseline for comparison. Option D's "doing okay" is a colloquial, non-technical vague assessment unsuitable for a reliability report.
4 / 5
Which sentence replaces the vague time expression "soon" with a precise technical commitment in a release plan?
"Deployed to production by 5 PM UTC on Friday, June 27" is correct: it gives a precise date, time, and time zone, which is essential for stakeholders coordinating around a release. Option A's "soon" is vague and gives no actionable deadline. Option C's "pretty soon, hopefully" compounds the vagueness with an uncertain hedge, weakening the commitment further. Option D's "before too long" is an equally imprecise, informal time expression unsuitable for a release plan.
5 / 5
A spec review flags vague language. Choose the sentence that replaces "a couple of edge cases" with precise, enumerated technical detail.
"Two edge cases to handle: empty input arrays and requests exceeding the 10 MB payload limit" is correct: it states the exact number of cases and enumerates each one precisely, giving engineers concrete requirements to implement and test against. Option A's "a couple of edge cases" is vague both in count and in content, naming nothing specific. Option B's "some edge cases...roughly speaking" adds further vagueness with the hedge "roughly speaking", undermining precision. Option D's "various edge case type things" is the vaguest and least technical phrasing, unsuitable for a spec.