Exercises — Chapter 3: Clarity

Writing is learned by writing. Most of these ask you to revise real-looking weak passages, because cutting bloat is a motor skill — you get it into your hands by doing it, not by reading about it. For open-ended tasks, a self-assessment rubric appears instead of a single "right" answer. Selected solutions: appendices/answers-to-selected.md.

How to work these: for every cut you make, name the defect (nominalization, empty opener, passive-with-no-reason, abstraction, unshared jargon, freeloader sentence). Cutting by named defect is what transfers to your own writing; cutting by feel does not.

Part A — Analyze This ⭐

Diagnose, don't yet rewrite. Name what's wrong (or right) and why.

A1. Name the specific defect in each sentence (one or two words is enough): - a) "It is important to note that the results were inconclusive." - b) "A decision regarding the budget will be made by the director." - c) "The system experienced sub-optimal performance characteristics." - d) "Due to the fact that the test failed, we will retry." - e) "There are several factors that contribute to the delay."

A2. Here are two versions of the same sentence. One is clearer. Which — and name the single move that made the difference? - a) "Utilization of the new framework resulted in an improvement of build times." - b) "The new framework improved build times."

A3. This passive sentence is actually correct — passive is the right choice. Explain why: "The blood samples were stored at −80 °C until analysis."

A4. This passive sentence is not correct — passive is hiding the actor and padding the sentence. Identify the buried actor and explain the cost: "It was determined that the deadline could not be met."

A5. Find the redundant modifier in each and explain what the noun already contains: - a) "advance planning" — b) "end result" — c) "completely eliminate" — d) "past history" — e) "unexpected surprise"

A6. Read this sentence and apply the "so what?" test. Does it earn its place? Justify: "In this section, we will now turn our attention to a discussion of the methodology employed in the study."

A7. Here is a sentence written for two different audiences. For each, say whether the jargon is a "door" or a "wall," and why: - To a database engineer: "The query did a full table scan because the index wasn't covering." - To a non-technical product manager: "The query did a full table scan because the index wasn't covering."

A8. This sentence is concise but unclear. Concision and clarity are not the same — explain what's unclear about it: "Optimize per spec before merge."

Part B — Revise This ⭐⭐

Rewrite each for clarity. Track your word count: aim to cut at least 30%. Name the defects you fixed.

B1. (Nominalizations) "The team undertook an evaluation of the vendor proposals and subsequently made a recommendation for the selection of the second option."

B2. (Empty phrases) "It should be mentioned that, due to the fact that we are currently in the process of conducting testing, we do not at this point in time have the ability to provide a definitive answer."

B3. (Passive with no reason) "Mistakes were made during the deployment process, and as a result the production environment was negatively impacted and a rollback had to be performed."

B4. (Abstraction) "The application has been experiencing some challenges related to its performance, which have had an impact on the overall user experience in a non-trivial way." (Invent plausible specifics to make it concrete.)

B5. (The throat-clearing email opener) "I hope you're doing well. I wanted to take a moment to reach out and touch base regarding a topic that I believe may be of some relevance to our ongoing discussions about the project timeline." (Rewrite so the first sentence does real work.)

B6. (Everything at once — a composite "before")

"It is generally the case that the implementation of new procedures within an organization will, more often than not, encounter a certain degree of resistance on the part of those individuals who are tasked with the adoption of said procedures, due in large part to the fact that change of any kind tends to produce a level of discomfort."

Cut this monster by at least half and name every defect you removed.

B7. (Redundant + nominalized) "The final outcome of our investigation into the matter was a determination that the root cause was attributable to a configuration error."

B8. (Honest hedge vs. empty hedge) Below, one hedge is honest and necessary; the rest are empty stacking. Keep the honest one, cut the rest: "It could potentially be the case that the observed effect might possibly be attributable, at least in part, to the new caching layer."

B9. (Science / methods — keep the right passive) This sentence is over-padded, but at least one passive in it is correct and should stay. Tighten everything else and justify the passive you keep: "The samples that had been collected were subsequently subjected to a process of centrifugation, after which it was observed that a separation of the components had been achieved."

B10. (Software / README — abstraction + nominalization) From a (composite) project README: "The configuration of the application is accomplished through the utilization of environment variables, the specification of which is a requirement prior to the initialization of the server." Rewrite as a sentence a developer could act on in one read.

B11. (Concrete + "so what?") A (composite) lab-report discussion sentence: "The results that were obtained from the experiment were generally found to be largely consistent with what had been expected based on the relevant theoretical predictions." Cut it hard, and decide whether — stripped of padding — it still earns its place or needs a concrete number to mean anything.

Part C — Write This ⭐⭐–⭐⭐⭐

Produce the document. Then run the eight-pass clarity checklist on your own draft and cut it.

C1. (Release note, two audiences) You fixed a bug where the mobile app would crash if a user rotated the screen during a file upload. Write two one-sentence release notes: one for a developer changelog (shared jargon allowed), one for end-user-facing notes (no unshared jargon). Then explain why neither is "dumbed down."

C2. (Status update, concrete) Your project is three weeks behind because a key dependency shipped late. Write a two-sentence status update to your manager. Constraints: lead with the fact that matters, be concrete (give the slip and its cause), no empty openers, active voice unless you can justify passive.

C3. (Methods sentence, defend the voice) Write one sentence describing a procedure (any field — a lab step, a deployment step, a data-cleaning step). Use the voice (active or passive) you think is right, then add a one-line justification for your choice using §3.3's three legitimate jobs for passive.

C4. (The "so what?" rewrite) Take this padded paragraph and rewrite it so that every sentence survives the "so what?" test. Delete any sentence that only sets up another:

"Performance is an important consideration for any web application. There are many factors that can affect performance. In our case, we looked into the performance of our checkout flow. What we found was interesting. The checkout flow was slow. We think we should make it faster."

C5. (Concrete from abstract — your own work) Find one genuinely abstract sentence you've written recently (a class assignment, a work email, anything). Rewrite it concretely. If you can't make it concrete because you don't have the specifics, write one sentence explaining what you'd need to find out — and notice that the vagueness was hiding a gap in your knowledge.

C6. (Introduce-once jargon) Write a two-sentence explanation, for a non-technical reader, of any one technical term from your field — using the "introduce the term once, plainly, then use it" pattern from §3.7. (Example shape: "X — a plain one-clause definition — caused the problem. Because X …")

Part D — Synthesis & Critical Thinking ⭐⭐⭐

D1. (Translate for three audiences) Here is a precise, jargon-rich technical sentence:

"The service exceeded its p99 latency SLO because a downstream dependency's connection pool saturated under load, triggering retries that amplified the request volume." Rewrite it three ways: (a) for a fellow backend engineer (you may keep all jargon), (b) for an engineering manager who is technical but not on this system, (c) for a non-technical executive. Then write two sentences on what changed and what stayed the same across the three.

D2. (Find the flaw in the advice) A writing guide says: "Always use active voice. Always prefer short words. Always cut to the bone." For each "always," give one concrete counterexample from this chapter where the rule produces worse writing. What's the better formulation of each rule?

D3. (Clarity ≠ dumbing down — defend it) A senior colleague insists their dense, jargon-heavy reports are "more rigorous" than your clear ones. Write a short, respectful response (3–5 sentences) that makes the simplicity vs. clarity distinction and the "density hides vagueness" point — without being condescending.

D4. (Diagnose, then prescribe) You're given a colleague's draft and told only "it's hard to read." You can't say more than "make it clearer" unless you can diagnose. List the eight clarity-checklist passes as a diagnostic checklist, and for each, write the specific question you'd ask of their draft. (This is the difference between useful and useless feedback — Chapter 12 builds on it.)

D5. (The hedge that's load-bearing) Find a published scientific abstract (or use one you have). Identify one hedge ("suggests," "may," "is consistent with") that is honest and necessary and one phrase that is empty padding. Explain why removing the first would make the writing dishonest but removing the second only makes it tighter.

Part M — Mixed Practice (Interleaved) ⭐⭐–⭐⭐⭐

These mix this chapter with Chapters 1 and 2, so you have to choose the right tool, not just apply the last thing you read.

M1. (Ch 2 + Ch 3) You wrote a clear, tight paragraph — every sentence earns its place, no bloat — and your reader still didn't understand it. The sentences are flawless. What did you most likely get wrong, and which chapter's tool do you reach for? (Hint: clarity is necessary but not sufficient.)

M2. (Ch 1 + Ch 3) You sit down to clarify a draft and discover you can't make one paragraph concrete — you keep writing "performance issues" because you don't actually know the numbers. Is this a clarity problem or a thinking problem? What does Chapter 1 say you should do, and how does §3.5 connect to it?

M3. (Ch 2 + Ch 3) Same outage, two release notes — one for developers, one for customers. The developer version is dense with shared jargon; the customer version uses plain concepts. A reviewer says "the customer one is dumbed down, make it as precise as the developer one." Using both chapters, explain why the reviewer is wrong.

M4. (Ch 1 + Ch 2 + Ch 3) Order these three questions the way you should actually ask them when starting a document, and say why the order matters: (i) "Have I cut every word that doesn't carry meaning?" (ii) "Who is my reader and what do they know?" (iii) "Do I actually understand this well enough to explain it?"

M5. (Ch 3 internal) You've been handed a paragraph and have time for only one pass before a deadline. Which of the eight clarity-checklist passes gives you the most improvement per minute, and why? (Defend your choice; there's a strong case for more than one answer.)

M6. (Ch 2 + Ch 3) Rewrite this expert-level sentence for the expert audience it's meant for — and resist the urge to "simplify" it. The trap here is over-clarifying: "The transaction observed a non-repeatable read under read-committed isolation." For a database audience, is there anything to cut or change? Justify keeping the jargon.

Part E — Extension ⭐⭐⭐⭐ (optional; Deep Dive track)

E1. (Quantify the gain) Take a 300–500 word document you wrote recently. Run the full clarity checklist and produce a tightened version. Then report three numbers: original word count, final word count, and percent cut. Estimate the reading-time saved (≈240 words/minute) and multiply by your realistic number of readers. Write one sentence on what that total attention cost was buying before you cut it.

E2. (Style-guide archaeology) Find the passive-voice and conciseness advice in two style references — e.g., Strunk & White's Elements of Style and the Microsoft or Google developer style guide. Where do they agree, where do they differ, and which gives better guidance on when passive is appropriate? Write a paragraph comparing them.

E3. (Build your own empty-phrase list) Over one week, collect ten empty phrases from your own field's writing (your inbox, your codebase's docs, papers you read) that aren't in the §3.4 table. For each, write the replacement. This becomes your personal sweep list — field-specific bloat is often invisible until you collect it.

Self-assessment rubric (for the "Write This" and open tasks): - Concision: Did you cut ≥30% from "revise" tasks without losing a fact? Can you name the defect behind each cut? - Voice: Is every passive sentence justified by one of the three legitimate jobs? Did you flip the unjustified ones? - Concreteness: Could a reader draw, number, or point at your key claims — or are you stuck at the top of the abstraction ladder? - Audience-fit (Ch 2): Does each specialized term match what this reader shares? No walls, no condescension. - Earns its place: Does every surviving sentence pass "so what?" — a fact, a claim, or a step toward a decision? - Honest: Did you keep load-bearing transitions and one calibrated hedge, rather than over-cutting into terseness?