Chapter 3: Clarity: How to Say What You Mean in the Fewest Possible Words

"Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts." — William Strunk Jr. & E. B. White, The Elements of Style

Chapter Overview

Here is a sentence from a real engineering status report, lightly anonymized:

"The implementation of the proposed methodology was undertaken subsequent to the completion of the initial phase of the preliminary investigation."

Twenty-three words. Read it again and try to extract the fact it contains. There is exactly one: they started testing after the first round of investigation. Seven words carry the entire payload. The other sixteen are packaging — and the packaging is so thick the reader has to dig to find the gift inside. A manager skimming forty status reports before a 9 a.m. meeting will not dig. She will skim, miss the point, and move on. The writer did the work; the writing buried it.

This chapter is about closing the gap between those two sentences — between what you meant and what you wrote. In Chapter 1 you saw that writing is thinking: the act of forcing a fuzzy idea into a sentence is what tells you whether the idea is actually clear in your head. In Chapter 2 you saw that audience decides everything — including, crucially, whether a technical term is a precise shortcut or a locked door. This chapter is where those two ideas become a craft you can practice on any sentence you will ever write. Clarity is not a personality trait some writers are born with. It is a set of specific, learnable moves: find the buried verb, name the actor, cut the empty opener, ask "so what?", and stop when the meaning is intact and nothing more can leave without taking information with it.

One promise, stated plainly because this chapter is about plain statements: if you internalize the moves in this chapter, your writing will visibly change — this week. Not your ideas, not your intelligence, not your field knowledge. Those were already there. What changes is that the reader will finally be able to see them. The single most common reaction to good editing is not "you made me smarter"; it is "oh — that's what I was trying to say." By the end of this chapter you will be able to take any paragraph you have written and cut it by a quarter while making it clearer, and you will know exactly why each cut works.

A warning before we start, because it's the most important idea in the chapter and the one most easily misheard. Cutting words is not the same as cutting content, and clarity is not the same as simplification. We will return to this repeatedly. A nuclear-reactor safety procedure should be clear, not simple — its precision is the entire point. The enemy of precision is not clarity. The enemy of precision is jargon used where it isn't shared, and bloat that hides the precise statement under a pile of words. Clear writing and precise writing are the same writing.

In this chapter, you will learn to:

• Diagnose why a sentence is wordy — name the specific defect, don't just feel that it's "too long."
• Convert nominalizations back into the strong verbs they were hiding ("make a decision" → "decide").
• Choose active or passive voice on purpose, and recognize the real cases where passive is the better choice.
• Cut the empty phrases ("it is important to note that," "due to the fact that," "there are") that pad almost every first draft.
• Run the "so what?" test and a reusable clarity checklist to take 20–40% off a draft without losing a single idea.

📕📗📘 Every track, read this whole chapter. Clarity is the one skill no field exempts you from. The engineer writing a spec, the developer writing a README, and the analyst writing a memo are all doing the same thing here: cutting the distance between meaning and words. The field-specific examples rotate so each track sees its own work, but the moves are identical. Do not skip the 📐 Project Checkpoint — it is where this becomes your writing, not just a demonstration.

3.1 What Clarity Actually Is (and the Three Myths That Block It)

Start with a concrete pair. Same fact, two sentences:

❌ Before: "It is generally the case that systems which have not undergone regular maintenance procedures will, over time, exhibit a tendency toward degraded performance characteristics." (24 words) ✅ After: "Unmaintained systems slow down." (4 words) Why it's better: Every word in the "after" carries information. "It is generally the case that" asserts nothing — it's a throat-clear. "Exhibit a tendency toward degraded performance characteristics" is six words for "slow down." We didn't lose a single idea; we lost twenty words of fog.

Now generalize. Clarity is the property of writing that lets a reader extract your meaning on the first pass, at full speed, without re-reading. That's the whole definition. Notice what it is not about: it is not about short words for their own sake, not about avoiding all complexity, and not about a particular reading level. It is about the reader's first pass. If your reader has to back up and re-read a sentence to parse it, that sentence has failed the test, no matter how impressive it looked.

Concision is clarity's twin, not its master. Concision is using no more words than the meaning requires. The two usually travel together — most unclear writing is unclear because it's padded — but they're distinct. You can be concise and unclear ("Optimize throughput per the spec" — concise, but which spec, optimize how?), and you can be clear and a little long (a careful safety warning that spells out every step). When they conflict, clarity wins. But ninety percent of the time, cutting words is how you buy clarity, because the extra words were the problem.

Three myths keep capable people from writing clearly. Name them so you can stop believing them.

Myth 1: "Sophisticated ideas need sophisticated prose." The reverse is true. The more complex the idea, the more the reader needs your sentences to be simple, because the reader is spending their working memory on the idea, not on decoding your grammar. Richard Feynman explained quantum electrodynamics to general audiences in plain words; the prose was simple precisely because the physics was hard. Dense prose around a hard idea doesn't signal that you're smart. It signals that you haven't finished thinking — recall Chapter 1: if you can't say it clearly, you may not yet understand it.

Myth 2: "Cutting words means cutting content." This is the big one, and it gets its own threshold concept below. Most first-draft words carry no information at all. They are the verbal equivalent of clearing your throat before speaking. Cutting them removes fog, not facts.

Myth 3: "Clear writing is dumbed-down writing." This confuses clarity with simplicity, two different things. Simplicity removes detail. Clarity removes obstacles to detail. A clear sentence can be extraordinarily precise — in fact, clarity is what lets precision land. We'll spend the last section of the chapter on this, because it's the myth that does the most damage: it makes smart people defend their bloat as "rigor."

🚪 Threshold Concept: Cutting words is not losing content. Before you cross this threshold, you read your draft and feel that every word is doing something — cutting feels like loss, like throwing away work you did. After you cross it, you read the same draft and see that most words are inert: openers that assert nothing, nominalizations hiding verbs, redundant pairs, hedges that don't qualify anything real. The shift is perceptual. You stop seeing "my words" and start seeing "information" and "packaging," and you become able to strip the packaging without anxiety because you can now see that the information is untouched. This is the single change that separates writers who revise from writers who only proofread. Until you can see the inert words, you can't cut them; once you can, you can't unsee them.

🔄 Check Your Understanding. A colleague defends a wordy sentence by saying, "But every detail in there is technically correct and necessary for precision." How do you respond — and what's the distinction they're missing?

Answer

They're conflating information with words. A sentence can contain only correct, necessary information and still drown it in inert packaging ("it is generally the case that," "exhibit a tendency toward"). The test isn't "is every fact necessary?" but "does every word carry a fact?" You can keep 100% of the precision while cutting 50% of the words, because the cut words weren't carrying the precision — they were hiding it. Precision lives in the nouns and verbs, not in the throat-clearing.

3.2 Strong Verbs vs. Nominalizations: The Highest-Leverage Fix

If you learn only one move from this chapter, learn this one. It fixes more bad sentences than any other single technique.

A nominalization is a verb (or adjective) that has been turned into a noun. Decide becomes decision. Analyze becomes analysis. Implement becomes implementation. Fail becomes failure. Move becomes movement. The word still names the action — but now the action is frozen into a thing, and because the sentence still needs a verb, a weak verb gets dragged in to prop it up: make a decision, conduct an analysis, undertake the implementation, experience a failure. The strong, specific verb you started with has been demoted to a noun, and a limp, generic verb has taken its place at the heart of the sentence.

Watch the damage and the repair:

❌ Before: "The team conducted an evaluation of the database performance and made a recommendation for the optimization of the indexing strategy." (20 words) ✅ After: "The team evaluated the database performance and recommended optimizing the indexing strategy." (12 words) Why it's better: Three nominalizations — evaluation, recommendation, optimization — were dragging three weak verbs behind them (conducted, made, the optimization of). Free the verbs (evaluated, recommended, optimizing) and the sentence loses 40% of its weight and gains all of its energy. The actor (the team) now does things instead of conducting and making them.

The diagnostic is mechanical, which is why it's so reliable. Look for these tells:

1. Abstract nouns ending in -tion, -ment, -ance, -ence, -ity, -ness, -al, -ing. Not all are nominalizations, but they're where nominalizations hide. Implementation, deployment, performance, dependence, reliability, robustness, approval, testing.
2. A weak verb propping up the noun. The usual suspects: make, conduct, perform, undertake, carry out, achieve, provide, experience, give, have, do, effect, facilitate. When you see "make a ," "conduct a ," "perform a ___," you've almost always found a buried verb.
3. The phrase "the [noun] of." The implementation of, the analysis of, the creation of, the reduction of. This is a nominalization wearing a flag. "The reduction of costs" wants to be "reduce costs."

Here is the repair move, and it has a name worth remembering: agent–action–object. Every clear sentence about something happening has an actor (the agent), an action (a strong verb), and usually a thing acted upon (the object). When a sentence feels mushy, ask: Who is doing what to what? Then rebuild around that.

❌ Before: "A determination regarding the allocation of additional resources will be made by management following a review of the proposal." (19 words) Ask: Who is doing what to what? → Management (agent) decides (action) whether to allocate resources (object), after reviewing the proposal. ✅ After: "Management will decide whether to allocate more resources after reviewing the proposal." (12 words) Why it's better: Two nominalizations (determination, allocation) and a passive prop (will be made by) collapsed into one strong verb (decide) with a clear agent (management). The reader instantly knows who acts and what they're deciding.

Notice that nominalizations don't just add words — they hide the actor. "A determination will be made" never says by whom. That ambiguity is sometimes deliberate (people nominalize to avoid committing to who's responsible — "mistakes were made"), but in technical writing it's usually just fog. Naming the agent is half the cure.

A field tour, so every track sees its own work:

CS / software (a code-review comment). ❌ Before: "The introduction of caching at this layer would result in a reduction of the number of redundant calls to the database." ✅ After: "Caching here would cut redundant database calls." (21 → 7 words.)

Science (a methods sentence). ❌ Before: "Quantification of the protein concentration was performed through the utilization of a Bradford assay." ✅ After: "We measured protein concentration with a Bradford assay." (Or, if your journal prefers passive: "Protein concentration was measured with a Bradford assay." — note we'll defend that passive in §3.3.) (13 → 8 words.)

Business (a status email). ❌ Before: "We are in the process of conducting an investigation into the root cause of the outage and will provide a notification upon the completion of our analysis." ✅ After: "We're investigating the outage's root cause and will notify you when we finish." (26 → 13 words — exactly half.)

⚠️ Not every nominalization is a crime. Some abstract nouns are the right word: evolution, civilization, recursion, inflation — there's no verb hiding underneath that you're suppressing, and the concept genuinely is a thing. And sometimes you nominalize on purpose to make an action the topic of a sentence so the next sentence can build on it (the given-new flow, coming in §3.5): "This reduction matters because…" The rule isn't "never nominalize." The rule is: don't let a strong verb get demoted to a noun for no reason. When you spot a nominalization, ask whether a verb is trapped inside and whether freeing it would help. Usually it would.

✏️ Try This. Find the buried verb and free it. Rewrite each in seven words or fewer: 1. "We performed an analysis of the results." 2. "The application of the patch led to the resolution of the bug." 3. "There was a failure of the backup system during the migration."

One set of answers

1. "We analyzed the results." (4) 2. "The patch fixed the bug." (5) 3. "The backup system failed during the migration." (7) — note we also killed the empty opener "there was."

3.3 Active vs. Passive Voice: Choose, Don't Default

You have probably been told "use active voice" and "avoid the passive." That advice is mostly right and importantly wrong, and the difference matters enough to spend a section on. The myth that passive voice is always an error has produced a generation of writers who either obey it blindly (and write worse in the cases where passive is correct) or ignore it entirely (and write worse everywhere else). The truth is a skill, not a rule: passive voice is a tool with three legitimate jobs, and a liability everywhere else.

First, make sure you can identify it, because many writers can't. A sentence is in the passive voice when the grammatical subject receives the action instead of performing it. The form is a be verb + past participle, often with a "by ___" phrase that names the real actor: "The bug was fixed by the on-call engineer." The active version flips it so the actor is the subject: "The on-call engineer fixed the bug." Active voice follows the natural agent–action–object order from §3.2; passive voice reverses it, putting the object first and the agent last (or dropping the agent entirely).

Why active is usually better:

❌ Before (passive): "It was observed that a significant increase in latency was caused by the deployment of the new service." (18 words) ✅ After (active): "The new service deployment caused latency to spike." (8 words) Why it's better: Passive forced two extra constructions ("it was observed that," "was caused by") and hid the actor at the end. Active puts the cause first, the effect second — which is also the logical order — and cuts the sentence in half. Most passive sentences are longer, slower, and vaguer than their active twins, and they invite the empty opener "it was [verb]ed that," which asserts nothing.

So why not ban it? Because in three situations, the passive is the better choice — not a tolerated exception but the right tool:

1. When the actor is unknown, irrelevant, or obvious. If you don't know who did it, can't say, or it genuinely doesn't matter, forcing an active sentence makes you invent or over-emphasize an actor.

✅ "The server was compromised at 3:14 a.m." — You don't yet know by whom; that's the point of the incident report. "Someone compromised the server" adds a vague, distracting "someone." ✅ "The samples were stored at −80 °C." — Who stored them is irrelevant; the temperature is the fact that matters.

2. In methods sections and procedures, by convention and for focus. Much of science still writes methods in the passive, and for a real reason: the method is the subject, not the experimenter. "The solution was titrated to pH 7.0" keeps the reader's attention on the procedure, which is what must be reproducible. (Conventions are shifting — many journals now accept and even prefer "We titrated…"; biology has moved toward active, chemistry less so. We cover field norms in Chapter 35. The point here: in a methods section, passive is a defensible craft choice, not a failure.)

3. To manage given–new flow — to keep the topic at the front of the sentence. This is the subtle one, and it's about cohesion, which we'll develop fully in Chapter 8. Readers attach a new sentence to the last thing they read. If the previous sentence ended on a concept, the next sentence should usually start there — even if that means using the passive.

✅ "The pipeline writes results to a staging table. That table is then scanned by the reconciliation job." The active alternative — "The reconciliation job then scans that table" — is fine, but the passive keeps "that table" at the front, right next to where the reader just left it, so the two sentences click together. Here passive serves flow, and flow serves the reader.

🔍 Why Does This Work? Why does the "actor unknown/irrelevant" case make passive the better choice rather than just an acceptable one? Think about what the active version forces you to do before reading on.

Answer

Active voice requires a subject that performs the action. If the real actor is unknown ("the server was compromised") or irrelevant ("the samples were stored at −80 °C"), the only way to write active is to supply a placeholder actor ("someone," "a technician," "we") — and that placeholder is either misleading (you don't actually know it was one "someone") or distracting (it pulls focus onto an actor the reader shouldn't care about). Passive lets you omit the actor cleanly, putting the spotlight exactly where the meaning is: on what happened, or on the conditions that matter. The grammar serves the meaning. This is why "avoid passive" is a heuristic, not a law — it's right whenever the actor matters, which is most of the time, and wrong precisely when the actor doesn't.

The practical rule, then: default to active, switch to passive on purpose. When you catch a passive in your draft, don't reflexively flip it — ask why it's passive. If the answer is one of the three jobs above, keep it. If the answer is "no reason; that's just how it came out" or "to sound formal" or "to avoid saying who's responsible," flip it to active. The flip almost always shortens the sentence and names the actor, which are two wins at once.

✏️ Try This. For each passive sentence, decide: flip to active, or keep passive? Justify in a few words. 1. "The deprecated endpoint will be removed in version 3.0." 2. "It was decided by the committee that the launch would be delayed." 3. "The cell cultures were incubated for 48 hours."

Answers

1. Keep passive (or rephrase). The actor — whoever pushes the release — is irrelevant; the fact is the removal and the version. "We will remove the deprecated endpoint in 3.0" is also fine if "we" is meaningful to the reader. Either works; the passive isn't wrong here. 2. Flip to active: "The committee decided to delay the launch." (12 → 6 words.) The actor (the committee) is known and relevant — naming it adds accountability — and "it was decided by" is pure padding. 3. Keep passive. Methods convention, and the actor (the researcher) is irrelevant; the incubation conditions are the reproducible fact.

3.4 Cutting the Empty Words: Phrases That Should Almost Always Die

Some phrases are reliable padding. They appear in nearly every first draft, they assert nothing, and you can delete or shrink them on sight. Memorize this list; it's the fastest way to cut 10–15% from any draft before you've even thought hard.

The redundant pairs in that last row deserve their own note. English is full of doublets that say the same thing twice: first and foremost, full and complete, null and void, various and sundry, each and every. And there's a whole class of redundant modifiers — adjectives that repeat what the noun already contains: advance planning (all planning is in advance), final outcome, end result, unexpected surprise, free gift, close proximity, basic fundamentals, actual fact, completely eliminate, absolutely essential, period of time. Cut the modifier; the noun already carried the meaning.

Watch how much disappears when you sweep a real paragraph for these:

❌ Before (composite project update, 71 words): "It is important to note that, due to the fact that the vendor was unable to deliver the components in a timely manner, we are currently in the process of making a decision with regard to whether or not we have the ability to meet the original deadline. In the event that we are not able to do so, a notification will be sent to all of the stakeholders at that point in time."

✅ After (28 words): "Because the vendor delivered the components late, we're deciding whether we can still meet the original deadline. If we can't, we'll notify all stakeholders."

Why it's better: We cut 43 words — 61% — and the meaning is more precise, not less. Gone: "it is important to note that" (asserts nothing), "due to the fact that" → "because," "in a timely manner" → "late" (and more specific), "in the process of making a decision with regard to whether or not" → "deciding whether," "have the ability to" → "can," "in the event that" → "if," "a notification will be sent" → "we'll notify" (active, named actor), "at that point in time" → (deleted; "if we can't" already establishes when). Notice that we didn't decide what to keep and cut by feel — every cut maps to a named defect from §3.2–3.4.

[📍 Good stopping point — you've now seen the three core cutting moves: free the verb, choose the voice, sweep the empty phrases. The rest of the chapter is about judgment: which words carry meaning, and how to know when to stop.]

🔄 Check Your Understanding. Without looking back, name three empty phrases you can delete or shrink on sight, and give the replacement for each.

Answer

Any three from the table, e.g.: "in order to" → "to"; "due to the fact that" → "because"; "it is important to note that" → (delete); "has the ability to" → "can"; "there are X that…" → make X the subject. If you can rattle off five without the table, you've internalized the sweep — it should become automatic, a first pass you run on every draft before you edit anything harder.

3.5 Concrete vs. Abstract: Make the Reader See It

Cutting words is half of clarity. The other half is choosing the right words — and the most common word-choice failure in technical writing is drifting too far up the abstraction ladder.

Picture a ladder. At the bottom are concrete, specific, sensory things: a 4-second page load, a $1.2M overrun, 300 dropped packets, a cracked weld. At the top are abstract, general categories: performance issues, budget challenges, network anomalies, structural concerns. Both ends are useful — abstraction lets you generalize and summarize — but writers under pressure tend to climb the ladder, because abstract language feels safer, more formal, and harder to be wrong about. The cost is that the reader can no longer see anything.

❌ Before (abstract): "The system experienced performance degradation that negatively impacted the user experience during peak utilization periods." ✅ After (concrete): "During the lunch rush, pages took 8 seconds to load and 12% of checkouts timed out." Why it's better: "Performance degradation" and "negatively impacted the user experience" are true but invisible — the reader can't picture them or act on them. "8 seconds" and "12% of checkouts timed out" are things a person can see, measure, and fix. Concrete language is also more honest: it can't hide behind vagueness. "Performance issues" could mean anything; "12% of checkouts timed out" commits to a claim.

The deeper point: abstraction is where vagueness hides. When you can't say something concretely, it's often because you don't yet know it concretely — which loops back to Chapter 1's thesis. "We need to improve our processes" survives precisely because it commits to nothing. "We need to cut the deploy time from 40 minutes to under 10" can be argued with, measured, and acted on. The discomfort of being concrete is the discomfort of being pin-down-able, and that discomfort is a feature: it's the writing forcing the thinking to finish.

This doesn't mean never abstract. Skilled writers move up and down the ladder deliberately: state the abstract claim, then ground it in a concrete instance, then perhaps generalize again. The failure mode is getting stuck at the top — paragraph after paragraph of "challenges," "solutions," "impacts," and "considerations" with nothing the reader can see. A good test: read your paragraph and ask, "Could I draw this? Could I put a number on it? Could I point at it?" If the answer is no for several sentences in a row, you've climbed too high.

A longer example — the abstract memo, grounded. ❌ Before: "Our team has been facing significant challenges related to resourcing and bandwidth, which have created downstream impacts on our ability to deliver against key milestones in a manner consistent with stakeholder expectations." (31 words, zero facts) ✅ After: "We're two engineers short, so the API migration will land March 15 instead of February 1 — six weeks late." (19 words, three facts: the cause, the slip, the magnitude) Why it's better: The "before" could describe any team in any company in any quarter — which is exactly why it's useless. The "after" tells the reader the cause (two engineers short), the consequence (migration slips), and the magnitude (six weeks). A reader can do something with the second version: reallocate people, reset expectations, or accept the slip. The first version just emits a mood.

🧩 Productive Struggle. Before reading the fix, try it yourself. Here is a sentence from a (composite) research abstract. It's abstract to the point of saying nothing. Rewrite it concretely — invent plausible specifics if you must, just to feel the difference: "The proposed approach demonstrated favorable results across a range of relevant performance metrics when compared to existing methods." Now ask: what would a reader actually need to know here? …

Discussion

A reader needs which metrics, how much better, and than what. A concrete version: "Our method cut median query latency by 38% (from 210 ms to 130 ms) and improved recall from 0.71 to 0.84, outperforming the BM25 baseline on all three benchmarks." Notice that the abstract version isn't just vaguer — it's unfalsifiable, and in science that's close to meaningless. "Favorable results across relevant metrics" is what people write when the results are weak or when they haven't decided what to claim. The struggle you just felt — I don't have the numbers to be concrete — is the whole lesson: vagueness is often a symptom of not-yet-finished thinking, not a style choice. If you genuinely don't have the numbers, the honest move is to get them, not to paper over the gap with abstraction.

3.6 The "So What?" Test: Does Every Sentence Earn Its Place?

The previous sections clean up sentences. This one decides whether a sentence should exist at all. It is the most ruthless tool in the chapter and the one that separates good editors from great ones.

After you've tightened a sentence, ask it one question: "So what?" What does this sentence do for the reader? Does it deliver a fact they need, support a claim, answer a question they'd have, or move them toward a decision? If you can't name the job it does — if the honest answer is "it sort of sets up the next sentence" or "it sounds thorough" or "it's context" with no further defense — the sentence is a candidate for deletion. Theme #6 of this book, stated as a working tool: every sentence must earn its place, because the reader's time is the scarcest resource your writing spends.

The "so what?" test kills three kinds of freeloaders:

1. The sentence that restates the obvious.

❌ "In this section, we will discuss the results. The results are an important part of any analysis. Below, the results are presented." — Three sentences, zero information; the reader can see it's the results section. Cut all three; show the results.

2. The sentence that says what you're about to say instead of saying it.

❌ "It is worth taking a moment to consider the implications of this finding." — Don't announce that you'll consider the implications. Consider them. The announcement is a sentence that exists only to delay the sentence that matters.

3. The "context" paragraph that's really procrastination. Technical writers love to "set the stage" — three paragraphs of background before the point. Sometimes the reader needs that background. Often it's the writer warming up, and the reader is waiting. The test: if I deleted this paragraph, would the reader be confused, or just faster? If just faster, cut it.

❌ Before (an email opening that won't get to the point): "I hope this email finds you well. I wanted to reach out to touch base regarding a matter that has come to my attention recently. As you may or may not be aware, there have been some developments related to the project that I think it would be valuable for us to discuss at your earliest convenience." (57 words) ✅ After: "Can we talk today? The vendor pushed our delivery date to March 15, which puts the launch at risk." (19 words) Why it's better: Every sentence in the "before" is a throat-clear — pleasantries, "I wanted to reach out," "a matter that has come to my attention," "as you may or may not be aware." None survives the "so what?" test. The "after" leads with the request (can we talk?) and the reason (the date slipped, the launch is at risk). The reader knows in two seconds what this email needs from them. We'll build the full anatomy of effective emails in Chapter 19; the engine under it is this test.

Apply "so what?" at three scales: to each sentence (does it carry a fact?), to each paragraph (does it advance the document, or just fill space?), and to the document (would the reader miss it if it were one page shorter?). A first draft that survives all three scales is rare and excellent. Most first drafts shed 20–40% under this test alone — and here is the reframe that makes that bearable: you are not deleting your work; you are removing the parts that were hiding your work. The reader sees a tighter, sharper document and thinks this person knows what they're talking about — which is precisely the impression all that deleted padding was trying, and failing, to create.

💡 Tip — the reading-time frame. Average adult reading speed is roughly 230–250 words per minute for ordinary prose, slower for dense technical text. When you cut a 1,000-word memo to 650, you didn't just "tighten it" — you handed every reader back about ninety seconds, and you raised the odds they finish it at all. Multiply by the number of readers. A widely-read document that's 30% shorter is a real, compounding gift of attention. That's not a metaphor; it's the actual resource your writing spends.

🔄 Check Your Understanding. What's the difference between the "so what?" test and the cutting moves in §3.2–3.4?

Answer

The cutting moves (free the verb, choose the voice, sweep empty phrases) make a sentence that should exist as tight as possible — they operate within a sentence. The "so what?" test asks whether the sentence should exist at all — it operates on the sentence. You run them in that order: first decide if the sentence earns its place ("so what?"), then, for the survivors, tighten the wording. No point polishing a sentence you're about to delete.

3.7 Jargon: A Door for Insiders, a Wall for Everyone Else

We promised in Chapter 2 that audience decides whether a technical term is a precision tool or a barrier. Here is where that becomes a clarity move you make sentence by sentence.

Jargon is specialized vocabulary shared by a field. It is not inherently bad — quite the opposite. Among people who share it, jargon is the most concise and precise option available. To a roomful of cardiologists, "the patient presented with an inferior STEMI" is faster and more exact than "the patient came in with a heart attack affecting the bottom part of the heart muscle, caused by a blocked artery." To a network engineer, "the handshake failed at the TLS layer" beats a paragraph of explanation. When the term is shared, jargon is clarity. Spelling it out for an expert audience would be the opposite of clear — it would be condescending and slow.

The failure is using jargon with an audience that doesn't share it — and worse, not realizing the audience doesn't share it. This is the curse of knowledge from Chapter 2 in its most concrete form: once a term is automatic to you, you forget it was ever opaque, so you sprinkle it into documents for non-specialists without noticing the wall you're building. Every unshared term is a small stumble: the reader either stops to look it up (you've lost their flow) or guesses and moves on (you've lost their accuracy) or quietly gives up (you've lost the reader).

❌ Before (a developer explaining an outage to a non-technical executive): "The root cause was a race condition in the connection pool that caused thread starvation under load, which cascaded into a backpressure failure upstream." ✅ After (same outage, same executive): "Under heavy traffic, two parts of the system tried to grab the same resource at the same moment and deadlocked. That backed up every request behind them, and the whole service stalled." Why it's better: Not one word cut — this one's actually longer — but every term is now one the executive shares. "Race condition," "thread starvation," and "backpressure" were precise to another engineer and were a wall to this reader. The fix wasn't "remove jargon"; it was "match the vocabulary to this audience." For an engineering postmortem, the first version is the clear one and the second would be patronizing. Same facts, two audiences, two right answers — exactly the principle from Chapter 2.

So the rule is not "avoid jargon." The rule is a question you ask of every specialized term: does my actual reader share this word?

• Yes → use it; it's the precise, concise choice. Spelling it out would insult them.
• No, but they need the concept → introduce it once, plainly, then use it. ("a race condition — when two operations collide because their timing overlaps — caused the outage.") Now you've taught the term and can use it for the rest of the document.
• No, and they don't need the term itself → replace it with plain language, as in the example above.

This is also where we kill the most dangerous myth in technical writing, the one §3.8 is devoted to: that jargon equals precision and plain language equals dumbing down. It's backwards. Jargon is precise only when shared. With the wrong audience, jargon isn't precise at all — it's noise, because precision that the reader can't decode carries no information. Clarity, not jargon, is what delivers precision to a reader who doesn't already share your vocabulary.

✏️ Try This. You're writing release notes that go to both developers and non-technical customers. The change: you fixed a bug where the app would lose unsaved data if the network dropped mid-sync. Write one sentence for each audience.

One set of answers

Developers: "Fixed a data-loss bug where an interrupted sync could drop un-flushed local writes before the retry." Customers: "Fixed a problem that could lose your unsaved changes if your connection dropped while the app was syncing." Same fix; the developer version uses shared terms ("flush," "retry") that would be a wall for customers, and the customer version uses concepts ("unsaved changes," "connection dropped") that an engineer would find imprecise. Neither is "dumbed down" — each is precise for its reader.

3.8 Clarity Is Not Dumbing Down: Keeping It Honest

This is the section to read twice, because it corrects the objection that lets smart people keep writing badly. Somewhere, someone is reading this chapter and thinking: My field is genuinely complex. If I write this simply, I'll lose the precision my work requires. Clarity is fine for emails, but my real work needs to be dense. That belief is wrong, and it's worth dismantling carefully, because it's sincere and it's common.

Start with the distinction the objection misses. Simplicity reduces complexity — it removes detail, nuance, and edge cases to make something easier. Clarity reduces obstacles — it removes the fog between the reader and your meaning, without removing meaning. They are different operations, and clarity does not require simplicity. You can write something fully as complex as your subject demands and still write it clearly. In fact, the more complex the subject, the more the reader needs clarity, because they have no spare attention to spend decoding your sentences.

A precise, complex idea, written clearly. Here's a genuinely technical claim, kept fully precise but written for clarity: "Under a read-committed isolation level, a transaction can see rows committed by other transactions after it began, so two identical queries within the same transaction may return different results — a non-repeatable read." That sentence is clear (you can parse it on one pass) and precise (it names the isolation level, the exact mechanism, and the technical term for the phenomenon). It loses nothing. It is not dumbed down. It is exactly as complex as the truth requires — and not one word more. Clarity didn't cost precision; clarity delivered precision to the reader's first pass.

Now the proof by contradiction. If "dense = precise" were true, then the densest writing would be the most precise. But you have read dense technical prose, and you know it is often the least precise — it is where vagueness hides, where unsupported claims slide past, where "performance was suboptimal" stands in for "we don't have the number." The Challenger O-ring memos (Chapter 2, and again in Chapter 4 and 38) are the grim case: the engineers were correct, and their warning was buried in dense, hedged, poorly structured prose. The density didn't make them more precise. It made them less persuasive, and people died. Clarity wasn't the enemy of their precision; the absence of clarity destroyed their precision's effect.

So state it as a law, the chapter's central theme: clarity is not the enemy of precision — jargon and bloat are. Precision lives in specific nouns, strong verbs, exact numbers, and named terms — every one of which is a clarity tool. Bloat (empty phrases, nominalizations, abstraction-ladder fog) is what hides precision. When you cut bloat and choose concrete words, you don't sacrifice precision; you expose it. The clearest writers in any field are usually its most precise thinkers, and that's not a coincidence — clarity is what thinking-finished looks like on the page.

A practical reassurance for the worried specialist: clarity does not mean you must explain every term to every reader. With an expert audience, the clear choice is the dense, jargon-rich version — because those readers share the vocabulary, and spelling it out would slow them down. Clarity is audience-relative (Chapter 2 again): it means "extractable on the first pass by this reader," not "simple in the abstract." Writing clearly for experts and writing clearly for the public are different targets, but they are the same skill — match the vocabulary and the framing to the reader, then cut everything that doesn't carry meaning for that reader.

🔄 Check Your Understanding. Someone says, "I can't write clearly because my field is too complex — clarity would mean dumbing it down." What's the single distinction that dissolves this objection?

Answer

Simplicity removes complexity; clarity removes obstacles to complexity. They're different operations. You can keep every bit of your field's complexity and still write it clearly — clarity doesn't ask you to remove detail, it asks you to remove the fog around the detail (empty phrases, buried verbs, abstraction). The proof: the densest prose is often the least precise, because density is where vagueness hides. Clarity delivers precision to the reader; it doesn't dilute it.

3.9 The Clarity Checklist: A Reusable Editing Pass

You now have the moves. Here they are as a single pass you can run on anything you write, in order, from "should this exist?" down to "is the wording tight?" Run it on a printout or a screen with the document at arm's length — the point is to read as a reader, not as the author who knows what it was supposed to say.

Two notes on using it. First, the order matters: "so what?" before everything, because deleting a sentence makes polishing it moot, and the wording passes (2–6) before the read-aloud (7), which is your final sensory check. Second, pass 7 — reading aloud — is not optional folk advice; it's the highest-yield proofreading technique that exists, because your ear catches what your eye skims. Your eye reads what it expects; your mouth reads what's there. Where you stumble reading aloud is almost always where the reader will stumble silently. (We'll return to read-aloud and the full editing hierarchy in Chapter 12.)

💡 Tip. Don't try to run all eight passes in one read on a long document — you'll do none of them well. Run pass 1 (so what?) as one read, passes 2–6 as a second read, and pass 7 (aloud) as a third. Three focused passes beat one distracted one. This is itself an instance of a bigger idea from Chapter 5: separate the kinds of editing instead of doing them all at once.

📐 Project Checkpoint

In Chapter 1 you wrote a portfolio charter — the subject you'll write about across all seven pieces — and in Chapter 2 you wrote a full audience profile for that subject (the K-R-A-C analysis: what your reader knows, their role, the action you want, their context). Now you'll make your first real cut, writing to the specific reader you profiled in Chapter 2. This is the first time you apply the before/after engine to your own writing rather than watching it applied to someone else's.

This chapter's increment: run the clarity checklist on one paragraph and cut it by at least 25%.

1. Pick the worst paragraph you have. From any portfolio piece you've started — the blog post, or a report, email, or abstract from your own work. Choose the densest, most abstract, most "professional-sounding" paragraph you can find. You want a real one, with real bloat, because cutting clean prose teaches nothing. If you have nothing drafted yet, write one quick, ugly paragraph explaining your blog-post topic — deliberately in your worst "formal" voice — and use that.
2. Count the words. Write the number at the top. This is your baseline; you can't measure a 25% cut without it.
3. Run the eight passes in order. So what? → sweep empty phrases → free the verbs → check the voice → get concrete → audience-check the jargon → read aloud → count the cut. For each cut you make, jot the pass number in the margin (P3: freed "make a decision"→"decide"). This is the crucial part: you're training yourself to cut by named defect, not by vague feel. Cutting by feel doesn't transfer; cutting by diagnosis does.
4. Count again. If you're not at least 25% shorter, you stopped too early — run passes 1 and 6 again, harder. Most first attempts on a genuinely bloated paragraph come in at 30–45%.
5. Read both versions aloud, back to back. Notice that the shorter one is also clearer and sounds more confident — not less. That's the whole lesson landing in your own writing.

Keep both versions (before and after) with the margin annotations. You'll reuse this exact pass on every piece in the portfolio, and in Chapter 12 (Editing and Revision) you'll fold it into a full multi-pass revision workflow. Next chapter (Structure) zooms out from the sentence to the whole document: even perfectly clear sentences fail if they're in an order the reader can't follow — clarity at the sentence level, structure at the document level.

3.10 Common Mistakes & Practical Considerations

Even writers who know these moves trip on the same edges. Here are the ones worth naming.

Over-cutting into terseness. Clarity is not minimalism. You can cut so hard that you strip out the connective tissue — the transitions, the "because," the brief context — that the reader needs to follow your logic. "Optimize cache. Reduce calls. Latency drops." is concise to the point of telegraphic; the reader has to reconstruct the relationships you removed. The goal is no more words than the meaning requires, and meaning includes the logical links between facts. Cut the inert words; keep the load-bearing ones. When in doubt, read it aloud — terseness sounds clipped and breathless, the same way bloat sounds padded.

Confusing short words with clear writing. Short words usually help, but clarity is about structure and word choice, not syllable count. "Use" is not always better than "utilize" because it's shorter — it's better because "utilize" is pretentious filler for "use" in 95% of cases. But "utilize" has a narrow correct meaning (to use something for a purpose other than its intended one), and there, the longer word is the precise one. Don't swap words for shorter words mechanically; swap them for more accurate words, which are usually but not always shorter.

Killing necessary hedges. Technical writing requires honest uncertainty. "The data suggest" is not weak writing when the data genuinely only suggest; overclaiming "the data prove" would be dishonest (and we'll treat this carefully in Chapter 35 on scientific writing). The clarity sin is empty hedging — "it could perhaps potentially be the case that this might possibly indicate" — stacking four hedges where one does the job. Keep the one honest hedge; cut the other three. Precision includes precisely calibrated uncertainty.

Editing for clarity while still drafting. If you run the clarity checklist on a sentence the moment you write it, you'll freeze — you can't generate and critique at the same time without one crippling the other. Clarity work is revision work. Draft messily, get the ideas down, then run the passes. (This is the core of Chapter 5; we flag it here because trying to clarify mid-draft is the most common way this chapter's advice backfires.)

The "but my boss/field writes this way" trap. You may work somewhere where bloated, passive, nominalized prose is the house style, and you may reasonably choose to match it to fit in. That's a real constraint. But know the difference between can't and won't: the bloat isn't required by your field's precision, it's required by your field's habit. You can usually write 20% clearer than the house style without anyone noticing it's "different" — they'll just notice your documents are easier to read. Clarity rarely gets punished; it usually gets you a reputation as the person whose memos people actually finish.

Decision framework — when you're unsure whether to cut:

Frequently Asked Questions

How do I write more clearly and concisely without losing important details?

You won't lose details, because the words you cut weren't carrying details — they were carrying fog. Run the clarity checklist in order: first ask "so what?" of each sentence (delete the ones that assert nothing), then sweep empty phrases ("it is important to note that," "due to the fact that"), free buried verbs from nominalizations ("make a decision" → "decide"), and replace abstractions with concrete specifics. The information lives in the nouns, verbs, and numbers; the bloat lives in the connective padding around them. You can routinely cut 25–40% while making the meaning more precise.

Is passive voice always wrong in technical writing?

No — that's a myth. Passive voice is the better choice in three cases: when the actor is unknown or irrelevant ("the server was compromised at 3:14 a.m."), in methods sections where the procedure (not the experimenter) is the subject ("the solution was titrated to pH 7.0"), and to keep a topic at the front of a sentence for smooth flow. The rule is default to active, switch to passive on purpose. When you find a passive in your draft, ask why it's passive; if there's no reason beyond "it sounds formal," flip it to active and name the actor.

What is a nominalization, and why should I avoid it?

A nominalization is a verb turned into a noun — decide becomes decision, implement becomes implementation. The problem is that the sentence still needs a verb, so a weak one gets dragged in to prop up the noun ("make a decision," "conduct an analysis"), and the strong, specific verb you started with is demoted. Nominalizations also hide the actor ("a decision was made" — by whom?). The fix: find the buried verb and free it, then rebuild around who does what to what (agent–action–object). It's the single highest-leverage clarity move.

Does writing clearly mean dumbing down my technical content?

No. Simplicity removes complexity; clarity removes the obstacles between the reader and your complexity. You can keep every bit of technical precision and still write clearly — in fact, dense prose is often less precise, because vagueness hides in it ("performance was suboptimal" instead of a real number). Clarity is also audience-relative: for an expert reader, the clear version is the jargon-rich one, because they share the vocabulary. The enemy of precision isn't clarity; it's jargon used with the wrong audience, and bloat that buries the precise statement.

How much should I cut from a first draft?

Expect to cut 20–40% from a typical first draft, and don't be alarmed by the high end — genuinely bloated drafts can lose half their words and improve. If you run the clarity checklist honestly and cut almost nothing, you didn't run it honestly; first drafts essentially always contain inert words because drafting and editing are different jobs (Chapter 5). The cut isn't loss — it's removing the packaging that was hiding your actual content.

Chapter Summary

Key Takeaways

• Clarity = the reader extracts your meaning on the first pass, at full speed, without re-reading. It's audience-relative, not an absolute reading level.
• Most first-draft words carry no information. Cutting them removes fog, not facts — the threshold concept of this chapter.
• Free the verb. Nominalizations ("make a decision," "the implementation of") are the highest-yield fix: recover the strong verb and rebuild around agent–action–object.
• Choose your voice. Default to active; use passive on purpose for unknown/irrelevant actors, methods sections, and given-new flow.
• Get concrete. "8 seconds and 12% of checkouts timed out" beats "performance degradation." Abstraction is where vagueness hides.
• Run "so what?" on every sentence. If it doesn't deliver a fact, support a claim, or move toward a decision, it's a candidate for deletion.
• Jargon is clarity when shared, a wall when not. The skill is asking, of each term: does this reader share it?
• Clarity is not dumbing down. Clarity is what delivers precision; jargon and bloat are what hide it.

Action Items

1. Memorize the §3.4 empty-phrase table well enough to sweep a draft in one pass.
2. On your next document, find every "make/conduct/perform a [noun]" and free the trapped verb.
3. For every passive sentence, write its reason in the margin; flip the ones with no reason.
4. Run the eight-pass clarity checklist on one portfolio paragraph and cut it ≥25% (the Project Checkpoint).
5. Read your next important document aloud before sending it.

Common Mistakes

• Over-cutting into terse, telegraphic prose that strips the logical links the reader needs.
• Swapping words for shorter words mechanically instead of for more accurate words.
• Killing honest hedges (keep one calibrated "the data suggest"; cut empty stacked hedges).
• Running the clarity checklist while still drafting — clarity is revision work.

Decision Framework — the one-line version: Does this word carry a fact for this reader? Keep it. Is it packaging — empty phrase, buried verb, redundancy, fog? Cut it. Is it a load-bearing transition or an honest hedge? Keep it. Everything in this chapter reduces to that question.

Spaced Review

A few questions reaching back, to strengthen retention.

1. (From Chapter 1) Chapter 1 argued that "writing is thinking." How does the experience of trying to make a sentence concrete (§3.5) demonstrate that thesis directly?
2. (From Chapter 2) Chapter 2 introduced the curse of knowledge. How does it explain why writers leave unshared jargon in documents for non-specialists (§3.7)?
3. (Bridging, Chapter 2 → 3) Chapter 2 said audience determines whether jargon helps or hurts. The race-condition example in §3.7 had two correct versions for two audiences. Reconcile that with this chapter's claim that you should "cut jargon." What's the actual rule?

What's Next

You can now make every sentence clear. But a document made of clear sentences can still fail — if those sentences are in an order the reader can't follow, or if the conclusion the reader needs is buried on page three. Clarity is a sentence- and word-level skill; the next level up is structure, the order and shape of the whole document. Chapter 4 shows why readers scan technical documents instead of reading them, and how to organize information — inverted pyramid, signposting, the conclusion first — so a scanning reader finds exactly what they need. The Challenger memos return there: their sentences weren't the main problem. Their structure was, and it cost seven lives. Clarity gets your meaning into each sentence; structure gets the reader to the right sentence.

Practice: Exercises · Quiz Go deeper: Case Study · Case Study 2 Review: Key Takeaways · Further Reading