Chapter 6: Sentences That Work: Grammar, Style, and the Mechanics of Clarity

"The difference between the almost right word and the right word is really a large matter — 'tis the difference between the lightning-bug and the lightning." — Mark Twain, letter to George Bainton, 1888

Chapter Overview

Here is a sentence from a real software design document, anonymized:

"After deploying the patch to production, the latency spikes that had been observed in the staging environment, which the on-call engineer had escalated the previous evening, were no longer occurring."

Read it once and try to answer a simple question: who deployed the patch? The sentence does not say. The opening phrase — After deploying the patch — needs an actor, and the first noun that follows is the latency spikes. Grammatically, the sentence claims that the latency spikes deployed the patch. That is a dangling modifier, and it is one of about twenty errors that turn up, over and over, in otherwise competent technical writing. None of them is a sign of low intelligence or weak ideas. They are the predictable failure modes of putting complex thoughts into linear sentences under deadline. And every one of them has a name, a cause, and a mechanical fix.

This chapter opens Part II, where the book zooms in from the philosophy of Part I to the craft of the page. Chapter 3 taught you to cut — to find the buried verb, sweep the empty phrase, ask "so what?" of every clause. That was about concision: removing words that carry no meaning. This chapter is about a different failure: sentences that are not bloated but broken — grammatically unsound in ways that make the reader stop, back up, and re-read. A comma splice doesn't add fog the way bloat does; it derails the reader's eye. A pronoun with no clear antecedent doesn't waste words; it forces a guess. These are precision failures, and in technical writing, where a misread instruction can crash a server or misdose a patient, they matter more than in almost any other kind of prose. By the end of this chapter you will be able to take a tangled sentence, name exactly what's wrong with it, and repair it — not by ear, but by rule.

A word about scope, because it sets your expectations. This is not a grammar course. We are not going to march through the eight parts of speech or diagram dependent clauses for their own sake. You learned most of English grammar by the age of six, intuitively, and you do not need a refresher on what a verb is. What you need is a targeted repair manual for the specific errors that plague technical writing — the ones that survive into final drafts because they're invisible to the writer who made them. The centerpiece of the chapter is an explicit, numbered list: the 20 most common technical-writing errors, each with a correction. Bookmark it; use it as a checklist on your next document. The before/after pair — broken sentence, then fixed sentence, with the rule named — is the engine of everything that follows. Every section runs on it.

In this chapter, you will learn to:

• Spot and repair dangling, misplaced, and squinting modifiers — the errors that quietly attach an action to the wrong actor.
• Fix pronoun ambiguity, especially the "this" with no referent that haunts technical prose.
• Tell a comma splice from a run-on, and choose among five distinct ways to fix each.
• Hold subject–verb agreement steady across long sentences where the subject and verb drift far apart.
• Build parallel structure so lists, comparisons, and series read as one shape instead of three.
• Vary sentence length and structure on purpose, and cut mechanics-level bloat the reader never sees you cut.

📕📗📘 All tracks, read this whole chapter. Sentence-level correctness is field-neutral: the dangling modifier that confuses a lab report confuses a pull-request description in exactly the same way. The examples rotate across engineering, software, science, business, and medicine so each track sees its own work, but the rules are identical for everyone. If you write in English at all, this chapter is for you. Pay special attention to §6.9, the numbered list of 20 — it is the chapter's most reusable artifact.

6.1 Why Sentences Break (and Why It's Not About Intelligence)

Start with a pair, because that's how this whole chapter works. Same intended meaning, two sentences:

❌ Before: "Having run the regression suite overnight, three new failures were discovered in the authentication module." (15 words) ✅ After: "Having run the regression suite overnight, the QA team discovered three new failures in the authentication module." (16 words) Why it's better: The opening phrase Having run the regression suite describes an action that needs a human doer. In the "before," the first thing the sentence offers as that doer is three new failures — which did not run anything. The "after" supplies the real actor (the QA team) right where the grammar expects it. The error wasn't wordiness; the fixed version is actually one word longer. The error was a broken connection between an action and its actor.

Notice what just happened. The fix did not make the sentence shorter or "simpler." It made it correct. This is the key difference between Chapter 3 and this one. Chapter 3 attacked sentences that were padded — full of inert words. This chapter attacks sentences that are malformed — wrong in their grammar, even when every word is necessary. A sentence can pass every clarity test in Chapter 3 (no nominalizations, active voice, concrete nouns) and still be broken, because clarity and correctness are different properties. You can have a tight, vivid, jargon-free sentence with a dangling modifier in it. The reader still stumbles.

So why do these errors happen, and why do they survive into final drafts written by smart, careful people? Three reasons, and naming them helps you catch your own.

First, you write in the order you think, not the order the reader parses. When you draft After deploying the patch…, the actor (you, the engineer) is so obvious in your head that you don't notice you never put it on the page. The grammar of the sentence and the contents of your mind have diverged, and you can't see the gap because your mind helpfully fills it. The reader's mind cannot.

Second, long sentences strain the machinery. A subject and its verb might sit six words apart, or sixteen. By the time you reach the verb, you've lost track of whether the subject was singular or plural. The set of test cases that cover the new endpoints — is that set (singular) or cases (plural)? The verb that follows reveals whether you kept track. Distance is the enemy of agreement, and technical writing is full of long, distance-heavy sentences.

Third — and this is the deep reason — these errors are invisible to the person who made them. This is the same curse of knowledge you met in Chapter 2, operating one level down. You know what you meant, so when you re-read, you read your intention, not your sentence. Your eye glides over the comma splice because your brain already knows the two ideas are related. A fresh reader, who has only the marks on the page, sees the splice. This is why the single most powerful tool in this chapter is not a rule but a habit: read it aloud, slowly, as if you'd never seen it. Your ear catches what your eye, primed by intention, skips.

🔄 Check Your Understanding. A colleague says, "I ran spell-check and grammar-check, and the document is clean." Why is that not enough to catch the errors in this chapter?

Answer

Most of the errors in this chapter are grammatically ambiguous, not grammatically illegal. A dangling modifier ("After deploying the patch, the spikes stopped") is a complete, parseable sentence — the checker sees a subject, a verb, and punctuation, and approves it. The error is that the sentence means something the writer didn't intend. Likewise, a pronoun "this" with no clear referent, a comma splice (which many checkers miss or flag inconsistently), and a subject–verb agreement error buried in a long sentence often pass automated tools. These errors live in meaning, and meaning is exactly what spell-check can't read. The catch requires a human — ideally one reading aloud.

The rest of this chapter is organized by error family, because catching errors works best when you hunt for one type at a time. We'll cover modifiers (§6.2), pronoun reference (§6.3), comma splices and run-ons (§6.4), agreement (§6.5), and parallelism (§6.6). Then we shift from fixing broken sentences to building good ones: variety (§6.7) and mechanics-level conciseness (§6.8). Section 6.9 gathers everything into the numbered list of 20.

6.2 Modifiers That Float Free: Dangling, Misplaced, and Squinting

A modifier is a word or phrase that describes something else in the sentence — an adjective, an adverb, or, most dangerously, an introductory phrase. The rule English enforces is simple and unforgiving: a modifier attaches to the nearest available noun. When the noun it lands on isn't the one you meant, the sentence says something you didn't.

There are three flavors, and technical writers hit all three.

Dangling modifiers — the action with no actor

A dangling modifier is an introductory phrase whose implied subject is missing from the sentence, so it grabs the wrong one. You met one in the overview. Here's another, from a methods section:

❌ Before: "To calibrate the sensor, a reference voltage of 5.0 V was applied." The problem: To calibrate the sensor implies a human doing the calibrating. The sentence's actual subject is a reference voltage, so the grammar claims the voltage calibrated the sensor — voltages don't calibrate things. ✅ After (option A, supply the actor): "To calibrate the sensor, we applied a reference voltage of 5.0 V." ✅ After (option B, rewrite the modifier): "For calibration, a reference voltage of 5.0 V was applied to the sensor." Why it's better: Option A names the doer (we) right after the comma, where the modifier expects it. Option B converts the verb phrase into a noun phrase (for calibration) that doesn't imply a human actor, so the passive construction is no longer dangling. Both are correct; choose by your field's voice conventions — many sciences prefer B's impersonal style, while software docs often prefer A's directness.

Dangling modifiers love the passive voice, because passive sentences often hide their actor — and a hidden actor is exactly what an introductory phrase needs and can't find. This is a direct callback to Chapter 3: when you choose passive voice (sometimes the right choice), watch the openings of your sentences, because that's where dangling modifiers breed.

A quick gallery, so the pattern burns in:

The diagnostic is reliable: when a sentence opens with an introductory phrase, the very next thing after the comma must be the person or thing doing the action in that phrase. Read the phrase, ask "who or what is doing this?", and check that the answer is the grammatical subject.

Misplaced modifiers — the right word in the wrong place

A misplaced modifier isn't missing its actor; it's just sitting next to the wrong word. The classic offender is only, which changes meaning depending on where it lands:

"The script only deletes files older than 30 days." (It only deletes them — doesn't archive or compress them.) "The script deletes only files older than 30 days." (It deletes nothing newer — the intended meaning in most cases.)

Same five words, two different guarantees. In a deletion script's documentation, that difference could destroy data. Place only, just, even, almost, and nearly immediately before the thing they limit.

A longer example:

❌ Before: "We need a database that can handle concurrent writes for our analytics pipeline that scales horizontally." The problem: Does that scales horizontally describe the database or the pipeline? It sits next to pipeline, so grammatically the pipeline scales — but you probably meant the database. ✅ After: "For our analytics pipeline, we need a database that handles concurrent writes and scales horizontally." Why it's better: Both descriptive clauses (handles concurrent writes, scales horizontally) now sit next to database, the thing they actually describe. Moving the pipeline phrase to the front clears the ambiguity entirely.

Squinting modifiers — the word that looks both ways

A squinting modifier sits between two things it could modify, and the reader can't tell which way it's looking:

❌ Before: "Engineers who write documentation rarely get promoted." The problem: Does rarely attach to write documentation (engineers who seldom document) or to get promoted (documenting engineers seldom get promoted)? It squints in both directions, and the two readings are opposites. ✅ After (reading 1): "Engineers who rarely write documentation get promoted." ✅ After (reading 2): "Engineers who write documentation are rarely promoted." Why it's better: Each fix moves rarely firmly to one side, killing the ambiguity. Which one you write depends on what you mean — but you must pick one.

✏️ Try This. Find the dangling modifier and fix it two ways (supply an actor, or rewrite the phrase): "When testing the new API, several undocumented error codes were returned." Then say in one sentence what the original grammar literally claims.

6.3 Pronoun Reference: The "This" That Refers to Nothing

A pronoun (it, this, that, they, these, which) is a stand-in for a noun that came earlier — its antecedent. The contract is strict: a pronoun must point to exactly one clear antecedent, and the reader must find it without effort. Technical writing breaks this contract constantly, in two ways.

Ambiguous "it" and "they" — which noun?

❌ Before: "The service calls the gateway, and then it logs the response." The problem: What is it — the service or the gateway? Both are plausible loggers. The reader has to guess, and a guess in a technical document is a defect. ✅ After: "The service calls the gateway, and then the gateway logs the response." Why it's better: Repeating the noun is not inelegant — it's precise. In technical writing, a repeated noun beats an ambiguous pronoun every time. The faint redundancy costs nothing; the ambiguity could cost an hour of an engineer's debugging.

This is a place where technical writing breaks from the rules of "good literary style." A novelist is taught to vary nouns and lean on pronouns to avoid repetition. A technical writer is taught the opposite: when in doubt, repeat the noun. Your reader is scanning, often skipping to a middle paragraph with no memory of what it referred to three sentences ago. Precision outranks elegance.

The orphan "this" — the single most common pronoun error in technical writing

Here is the error you will catch in your own drafts more than any other in this chapter. A writer finishes a paragraph, then opens the next sentence with This means… or This is a problem because… — where this refers not to a single noun but to the entire fuzzy cloud of the previous paragraph.

❌ Before: "The cache invalidation runs on a fixed 60-second timer, the database replicas lag by up to 12 seconds under load, and the API gateway caches aggressively. This is why users sometimes see stale data." The problem: This refers to… all three facts? The interaction between them? The reader is handed a pronoun with no single noun behind it and must reconstruct the antecedent from a paragraph of candidates. The sentence feels connected to the writer, who knows which combination causes stale data. To the reader, this is an orphan. ✅ After: "The cache invalidation runs on a fixed 60-second timer, the database replicas lag by up to 12 seconds under load, and the API gateway caches aggressively. This combination of stale caches and lagging replicas is why users sometimes see stale data." Why it's better: The fix is mechanical and worth memorizing: never let "this" stand alone — give it a noun. This combination, this lag, this timing mismatch. The moment you force yourself to name the noun after this, one of two things happens: either you name it cleanly (and the reader is grateful), or you discover you can't name it — which means you hadn't actually pinned down what you were claiming. That second case is the writing-is-thinking thesis from Chapter 1, catching you in the act. The orphan this is often a symptom of unfinished thought.

🔍 Why Does This Work? Why is "give every this a noun" such a high-yield rule — and what is it really fixing underneath the grammar?

Answer

On the surface, it removes ambiguity: the reader gets a concrete antecedent instead of a vague gesture. But the deeper reason is that the rule forces a diagnostic. To name the noun after this, you must consciously identify the one thing you're referring to. Often you can't — the previous paragraph established three facts and you meant "the way they interact," but you hadn't articulated that interaction even to yourself. The orphan this was a placeholder for a thought you hadn't finished. Forcing the noun forces the thought to finish. So the rule is doing double duty: it sharpens the sentence for the reader and it surfaces gaps in your own reasoning. That's why it feels uncomfortable to apply — it's not just editing, it's thinking. (This is the Chapter 1 thesis operating at the level of a single pronoun.)

"Which" with a fuzzy antecedent

The same orphan problem afflicts which:

❌ Before: "The migration ran for six hours and locked the orders table, which delayed the nightly batch jobs." The problem: Which delayed the batch jobs — the six-hour duration, the table lock, or both? Probably the lock, but the grammar points at the nearest noun (table), and a table doesn't delay jobs. ✅ After: "The migration locked the orders table for six hours, and the lock delayed the nightly batch jobs." Why it's better: Replacing the broad which with a named noun (the lock) pins the cause precisely. When which refers to a whole clause rather than a single noun, it's almost always clearer to start a new clause with the specific noun.

[📍 Good stopping point — you've covered modifiers and pronoun reference, the two most common ambiguity errors. The next section, comma splices and run-ons, is the most common punctuation error family.]

6.4 Comma Splices and Run-Ons: Where One Sentence Ends and the Next Begins

These are the most frequent punctuation errors in technical writing, and they're worth a careful treatment because the fix involves a real choice about meaning, not just a mechanical swap.

First, the definitions, with concrete examples.

A comma splice joins two complete sentences (two independent clauses — each could stand alone) with only a comma:

"The build passed all tests, we deployed to production." ← comma splice

A run-on (or fused sentence) joins two complete sentences with no punctuation at all:

"The build passed all tests we deployed to production." ← run-on

Both errors come from the same root: the writer felt the two ideas were closely related — and they are — so they ran them together. The relationship is real; the punctuation just isn't strong enough to carry the join. A comma can separate items in a list or set off a phrase, but it cannot, on its own, weld two independent sentences together. That job needs a stronger connector.

Here is the part most grammar guides skip: there are five distinct ways to fix a comma splice or run-on, and they are not interchangeable — each one expresses a different relationship between the two ideas. Choosing among them is a writing decision, not a mechanical one.

Take this comma splice and watch all five fixes:

❌ Before: "The cache hit rate dropped to 40%, response times doubled."

Fix 1 — Period (two separate sentences). Use when the ideas are related but each deserves its own emphasis.

✅ "The cache hit rate dropped to 40%. Response times doubled." Effect: Clipped, factual, two distinct hammer-blows. Good for impact.

Fix 2 — Semicolon. Use when the ideas are closely linked and you want to signal that link without naming it.

✅ "The cache hit rate dropped to 40%; response times doubled." Effect: Says "these two belong together" more strongly than a period, without specifying how.

Fix 3 — Comma + coordinating conjunction (FANBOYS: for, and, nor, but, or, yet, so). Use when you want to name the relationship as additive, contrastive, or causal.

✅ "The cache hit rate dropped to 40%, so response times doubled." Effect: So makes the causal link explicit — the drop caused the doubling. (Note: the comma is correct because a coordinating conjunction follows it. A comma alone was the error.)

Fix 4 — Subordination (make one clause dependent). Use when one idea is the cause or condition and the other is the result — this is often the most precise fix.

✅ "When the cache hit rate dropped to 40%, response times doubled." Effect: Subordinating when turns the first clause into the setup and the second into the payoff. It shows which idea is primary (the doubling) and which is the condition (the drop). Subordination is the technical writer's most underused tool — it encodes logical hierarchy directly into grammar.

Fix 5 — Semicolon + conjunctive adverb (however, therefore, consequently, moreover). Use for a formal, explicit logical link.

✅ "The cache hit rate dropped to 40%; consequently, response times doubled." Effect: The most formal option. The conjunctive adverb names the relationship precisely. (Watch the punctuation: semicolon before the adverb, comma after it. A common error is using a comma before however — that just creates a new comma splice.)

So which fix should you use? It depends on the relationship you want to express:

The lesson goes beyond punctuation. A comma splice is often a sign that you haven't decided how two ideas relate. The comma is a hedge — "these go together somehow." When you pick a real fix, you're forced to specify: is it cause and effect (so, because)? Contrast (but, although)? Simple sequence (then)? That decision sharpens the logic, not just the grammar. This is the same pattern as the orphan this: the grammatical error is the visible symptom of an unmade decision underneath.

🧩 Productive Struggle. Before reading on, fix this run-on in three different ways, and for each, write one sentence describing the relationship your fix implies between the two ideas: "The legacy module has no tests refactoring it is risky." Try it before you look.

One set of answers

• Subordination (cause): "Because the legacy module has no tests, refactoring it is risky." — Implies the lack of tests is the reason refactoring is risky. (Usually the best fix: it names the causal logic.)
• Semicolon + adverb: "The legacy module has no tests; therefore, refactoring it is risky." — Same logic, more formal register.
• Comma + FANBOYS: "The legacy module has no tests, so refactoring it is risky." — Same causal logic, lighter and more conversational than therefore.
• (A period would also be correct — "The legacy module has no tests. Refactoring it is risky." — but it drops the explicit causal link, leaving the reader to infer it. In a risk assessment, you usually want the cause stated.)

The point: every fix is grammatically correct, but they don't all say the same thing. The run-on hid a decision; fixing it forced you to make it.

One special warning, because it causes more comma splices than anything else: conjunctive adverbs are not conjunctions. However, therefore, thus, hence, moreover, consequently, nevertheless, furthermore — these feel like they can join two sentences with a comma, but they can't. "The tests passed, however we rolled back" is a comma splice. It needs a semicolon or a period: "The tests passed; however, we rolled back." This single error — comma-plus-however — may be the most common punctuation mistake in professional writing. Watch for it.

6.5 Subject–Verb Agreement Across Long Sentences

The rule is the first one you ever learned: a singular subject takes a singular verb, a plural subject a plural verb. The server responds. The servers respond. You never get this wrong in a four-word sentence. You get it wrong when the subject and verb drift far apart — which is exactly what happens in the long, qualifier-heavy sentences technical writing produces.

The error has a signature: a long phrase intervenes between the subject and the verb, and the verb agrees with the nearest noun instead of the real subject.

❌ Before: "The list of approved vendors who have passed the new security audit and submitted updated insurance certificates are posted on the intranet." The problem: What is the subject — list (singular) or vendors (plural)? It's list: one list is posted. But by the time you reach the verb, vendors is the nearest noun, so the writer's ear chose are. The real subject is singular. ✅ After: "The list of approved vendors who have passed the new security audit and submitted updated insurance certificates is posted on the intranet." Why it's better: List … is — subject and verb agree. The trick to catching this: mentally delete the intervening phrase. "The list … is posted." With the qualifiers stripped, the agreement is obvious. The qualifiers were noise drowning out the subject.

That deletion trick is the whole technique. Find the verb, then find its real subject by stripping every intervening phrase, and check that they agree in number. Long technical sentences pile up prepositional phrases (of vendors, with certificates), relative clauses (who have passed), and parentheticals between the subject and verb. Strip them all and the skeleton is short: The list is posted.

A few specific traps that catch even careful writers:

"Each," "every," "either," "neither," "none" are singular.

❌ "Each of the microservices have their own database." ✅ "Each of the microservices has its own database." (Each is the subject, not microservices.)

Phrases like "along with," "as well as," "in addition to," "together with" do NOT make a singular subject plural.

❌ "The primary database, along with its read replicas, are backed up nightly." ✅ "The primary database, along with its read replicas, is backed up nightly." (The subject is database, singular; the along with phrase is a parenthetical, not part of the subject.)

Collective nouns (team, group, set, data) take a singular verb in American English when acting as a unit.

✅ "The team is shipping on Friday." (one unit) Note on data: strictly a Latin plural (datum/data), and many style guides — especially in the sciences — still require "the data are." In general and business writing, "the data is" is now widely accepted as a collective singular. Know your field's convention and be consistent within a document. This is one of the few agreement questions where the "right" answer is genuinely audience-dependent.

🔄 Check Your Understanding. Fix the agreement and name the real subject: "The combination of high request volume, slow database queries, and an undersized connection pool were responsible for the outage."

Answer

The real subject is combination (singular) — one combination of factors. Strip the intervening phrase of high request volume, slow database queries, and an undersized connection pool and you're left with "The combination … were responsible," which exposes the error. Fixed: "The combination of high request volume, slow database queries, and an undersized connection pool was responsible for the outage." The three plural-sounding nouns inside the phrase pulled the writer's ear toward were, but they're objects of the preposition of, not the subject.

6.6 Faulty Parallelism: Making Lists and Comparisons Hold Their Shape

Parallelism means that elements playing the same grammatical role share the same grammatical form. When you write a list, a series, or a comparison, every item should be the same kind of thing — all verbs, all nouns, all clauses. When they aren't, the sentence lurches, and the reader feels the bump even if they can't name it.

This matters intensely in technical writing because technical writing is full of lists: feature lists, step sequences, requirement enumerations, bullet points. Each is a parallelism trap.

Start with a sentence-level series:

❌ Before: "The new pipeline ingests raw logs, parsing them into structured events, and then it stores the results in the warehouse." The problem: Three actions in a series, three different grammatical shapes: ingests (simple verb), parsing (participle), it stores (new clause with subject). The series promised three parallel items and delivered three mismatched ones. ✅ After: "The new pipeline ingests raw logs, parses them into structured events, and stores the results in the warehouse." Why it's better: Three simple present-tense verbs (ingests, parses, stores), all sharing the one subject (the pipeline). The sentence now has a clean three-beat rhythm. The reader's eye recognizes the shape and reads at full speed.

Faulty parallelism is most visible — and most common — in bulleted lists. Watch:

❌ Before: The deployment checklist: - Run the test suite - Database migrations should be applied - Verifying the health-check endpoint - You need to notify the on-call engineer

The problem: Four items, four grammatical forms: an imperative (Run), a passive statement (should be applied), a participle (Verifying), and a second-person sentence (You need to). The list reads like four people wrote it. ✅ After: The deployment checklist: - Run the test suite - Apply the database migrations - Verify the health-check endpoint - Notify the on-call engineer

Why it's better: Every item is now an imperative verb (Run, Apply, Verify, Notify) — the right choice for a checklist, because each item is an action the reader performs. The list reads as one instrument. (Imperative is the standard for procedures; you'll see why in Chapter 22 on instructions.)

Parallelism also governs correlative pairs — both…and, either…or, neither…nor, not only…but also. Whatever follows the first half must match, grammatically, whatever follows the second:

❌ Before: "The API not only handles authentication but also it manages rate limiting." The problem: not only is followed by a verb (handles); but also is followed by a clause (it manages). Mismatch. ✅ After: "The API not only handles authentication but also manages rate limiting." Why it's better: Now both halves are followed by a verb (handles, manages). The pair balances.

And it governs comparisons — the two things compared must be grammatically and logically comparable:

❌ Before: "The latency of the new endpoint is lower than the old API." The problem: This compares the latency (a measurement) to the old API (a system). You can't compare a number to an API. ✅ After: "The latency of the new endpoint is lower than that of the old API." Why it's better: That of supplies the missing latency, so now you're comparing latency to latency — measurement to measurement. (This "comparing apples to systems" error is rampant in benchmarking write-ups.)

The deep value of parallelism is that it makes structure visible. When three items share a shape, the reader instantly sees they're peers — three equal steps, three coordinate features. Faulty parallelism hides that structure; the reader can't tell at a glance whether the items are parallel or nested. Parallel form is structure you can see. That ties directly to Chapter 4: structure serves the reader, and parallelism is structure operating at the sentence level.

✏️ Try This. Fix the parallelism: "To improve onboarding, we should rewrite the README, the tutorial needs screenshots, and adding a troubleshooting section." Make all three items the same grammatical shape. (Hint: three actions, three matching verbs.)

6.7 Sentence Variety: Why All-Long and All-Short Both Fail

We now leave the world of errors and enter the world of craft. A sentence can be perfectly correct — no dangling modifier, no comma splice, agreement intact — and still be part of bad prose, because the rhythm of the sentences around it is monotonous. Variety is what turns a string of correct sentences into readable writing.

Two failure modes bracket the problem.

All-long prose exhausts the reader. Every sentence carries three clauses, two qualifiers, and a parenthetical, and by the third one the reader is rationing working memory just to track where each sentence is going. Here's a real-sounding example:

❌ Before (all long): "The migration, which had been scheduled for the maintenance window on Saturday after the team confirmed that the staging environment matched production, was delayed because the backup process, which normally completes in two hours, took nearly five hours due to the unexpectedly large size of the audit-log table that had not been pruned since the previous quarter." (one 62-word sentence)

That is grammatically correct. It is also miserable to read. Every clause defers the point; the reader holds five suspended phrases waiting for resolution.

✅ After (varied): "The migration was scheduled for Saturday's maintenance window. The team had confirmed staging matched production. But the backup ran long — nearly five hours instead of the usual two — because the audit-log table had ballooned. No one had pruned it since the previous quarter." (four sentences: 9, 7, 19, 9 words) Why it's better: The 62-word monster became four sentences of varying length. The short ones ("The team had confirmed staging matched production.") let the reader breathe and land a fact. The one longer sentence carries the causal chain. The variation creates rhythm — and rhythm is what keeps a reader moving.

All-short prose is the opposite failure, and technical writers fall into it when they over-apply Chapter 3's "cut, cut, cut":

❌ Before (all short): "The cache failed. Requests hit the database. The database slowed. Connections piled up. The pool exhausted. The service went down. Users saw errors. We paged on-call." (eight choppy sentences) The problem: Every sentence is the same length and the same shape: subject-verb, four or five words, full stop. It reads like a telegram or a robot. There's no signal about which fact is the cause and which is the effect — they're all flattened to the same weight. Worse, the staccato rhythm is tiring in its own way; the reader's eye keeps slamming into periods. ✅ After (varied + subordinated): "When the cache failed, requests slammed straight into the database, which slowed under the load. Connections piled up until the pool was exhausted, and the service went down. On-call got paged; users saw errors." (three sentences, with subordination showing cause and effect) Why it's better: Subordination (When the cache failed…) and coordination (until…, and…) now encode the causal chain that the choppy version flattened. The reader sees which fact caused which. And the rhythm varies — a longer opening sentence, a medium one, a short punch to close.

So the principle is not "write short sentences" (that was a partial reading of Chapter 3) and not "write sophisticated long sentences." It's this: vary length and structure to match the weight of your ideas, and use the variation itself to guide the reader. Short sentences land facts and create emphasis. Longer sentences carry relationships, sequences, and qualifications. A short sentence after several long ones hits — readers feel it. That's a tool.

Two practical moves:

Use a short sentence for emphasis, deliberately. After a complex explanation, a four-word sentence lands like a verdict. "The data was never encrypted." It works because of the contrast with the longer sentences around it. If every sentence were that short, none would stand out.

Vary your openings, not just your lengths. Prose where every sentence starts with the subject (The system… The user… The result…) feels mechanical even when the lengths vary. Open some sentences with a subordinate clause (When the request arrives…), some with a transition (However…), some with a prepositional phrase (Under heavy load…). This is also where you cash in the subordination skill from §6.4.

🔍 Why Does This Work? Why does a single short sentence dropped into a passage of longer ones create emphasis — what's the underlying mechanism?

Answer

Emphasis is created by contrast, not by any property of the short sentence itself. The reader has built up an expectation — sentences here run 20–30 words, full of clauses. A sudden 5-word sentence violates that expectation, and the violation makes the reader's eye snag on it. The pattern break is the emphasis. This is why the technique only works in moderation: if you write five short sentences in a row, there's no longer a contrast, so there's no emphasis — you've just made everything choppy and flat (the all-short failure). Rhythm is relational. A short sentence is only "short" relative to its neighbors, and that relativity is exactly what you're using as an emphasis tool. The same logic explains why an occasional long, flowing sentence stands out in mostly-short prose: contrast cuts both ways.

6.8 Conciseness at the Mechanics Level: The Cuts the Reader Never Sees

Chapter 3 taught conciseness as a revision strategy — cut 25–40%, sweep empty phrases, free buried verbs. This section is the sentence-mechanics complement: a handful of specific constructions that pad sentences and have clean, mechanical fixes. These are the cuts so small the reader never notices them individually, but together they tighten every sentence you write.

Expletive constructions: "it is" and "there are." An expletive here is a grammatical placeholder — it or there used as an empty subject that delays the real one. They aren't always wrong ("It is raining" has no better form), but in technical writing they usually bury the real subject behind dead words.

❌ "There are three services that depend on the auth module." → ✅ "Three services depend on the auth module." (Make the real subject — services — the grammatical subject.) ❌ "It is necessary for the client to refresh the token every hour." → ✅ "The client must refresh the token every hour." (The expletive it is necessary for hid the real actor, the client, and the real verb, must refresh.) ❌ "There is a flag that controls verbose logging." → ✅ "A flag controls verbose logging."

The diagnostic: when a sentence starts with There is, There are, It is, or It was followed by a noun and that, you can almost always recover a stronger sentence by deleting the expletive and promoting the buried subject.

"In order to" → "to." Almost always, in order to can shed in order with zero loss:

❌ "In order to deploy, run the build script." → ✅ "To deploy, run the build script." (Rare exception: when omitting it creates a momentary misreading. Those are rare; default to cutting.)

"Due to the fact that," "owing to the fact that," "in spite of the fact that." These are wordy connectors with one-word equivalents:

❌ "The release slipped due to the fact that QA found a blocker." → ✅ "The release slipped because QA found a blocker." In spite of the fact that → although. In the event that → if. For the purpose of → to or for. Any phrase containing the fact that is a candidate for compression.

A reference table of the worst mechanics-level offenders, all with one-word or near-one-word fixes:

Redundant pairs and modifiers. Technical writing collects redundancies where one word already contains the other:

advance planning (planning is always in advance) → planning end result → result; final outcome → outcome; past history → history completely eliminate (eliminate is total) → eliminate; exact same → same close proximity → proximity; unexpected surprise → surprise; future plans → plans

None of these single cuts changes a sentence much. The point is cumulative: a document with fifty of these is meaningfully heavier than one with none, and the reader feels the weight without knowing why. This is the "best writing is invisible" theme at the smallest scale — the reader never notices the words you cut, only that your prose moves.

🔄 Check Your Understanding. Tighten this sentence using the mechanics moves from this section, and name each move you make: "There are a number of factors that, due to the fact that they were not accounted for, had the ability to cause the outage."

Answer

"Several unaccounted-for factors could have caused the outage." (12 words → ~8, and clearer.) Moves: (1) Expletive — deleted there are … that, promoted factors to subject. (2) a number of → several. (3) due to the fact that they were not accounted for → folded into the adjective unaccounted-for. (4) had the ability to → could. Each move is small; together they cut a third of the sentence and expose the actual claim, which the padding had buried.

6.9 The 20 Most Common Technical-Writing Errors, with Corrections

This is the chapter's most reusable artifact. Bookmark it. Before you send your next important document, run down this list — each error has a one-line diagnostic so you can hunt for it on purpose. They're grouped by family for learning; on a real proofreading pass you'll scan for all twenty.

Modifiers

1. Dangling modifier — an opening phrase whose actor is missing. - ❌ "After deploying the patch, the latency dropped." → ✅ "After deploying the patch, we saw the latency drop." - Diagnostic: After every opening comma, is the next word the doer of the opening phrase?

2. Misplaced modifier — a word sitting next to the wrong target. - ❌ "The script only deletes old files." → ✅ "The script deletes only old files." - Diagnostic: Does only / just / even / nearly sit immediately before what it limits?

3. Squinting modifier — a word that could modify the clause on either side. - ❌ "Engineers who document code rarely get promoted." → ✅ "Engineers who document code are rarely promoted." (or move it the other way) - Diagnostic: Can the middle adverb attach to two different verbs?

Pronoun reference

4. Orphan "this" / "that" — a demonstrative pronoun with no single noun behind it. - ❌ "…This is why it fails." → ✅ "…This timing mismatch is why it fails." - Diagnostic: Does every this / that have a noun right after it? If not, add one.

5. Ambiguous "it" / "they" — a pronoun that could point to two nouns. - ❌ "The service calls the gateway, then it logs." → ✅ "…then the gateway logs." - Diagnostic: For each it / they, is there exactly one possible antecedent? When in doubt, repeat the noun.

6. Vague "which" — which referring to a whole clause, not a noun. - ❌ "The job locked the table, which delayed everything." → ✅ "…and the lock delayed everything." - Diagnostic: Does which point at one noun, or at a fuzzy clause?

Sentence boundaries

7. Comma splice — two complete sentences joined by only a comma. - ❌ "Tests passed, we deployed." → ✅ "Tests passed, so we deployed." (or period / semicolon) - Diagnostic: Could the text on each side of the comma stand alone as a sentence? Then the comma is too weak.

8. Run-on / fused sentence — two complete sentences with no punctuation between. - ❌ "The disk filled the service crashed." → ✅ "When the disk filled, the service crashed." - Diagnostic: Read aloud — do you hear two sentences with no stop between them?

9. Comma before a conjunctive adverb — the however / therefore splice. - ❌ "It passed, however we rolled back." → ✅ "It passed; however, we rolled back." - Diagnostic: Is there a comma before however / therefore / thus / moreover? It usually needs a semicolon.

Agreement and consistency

10. Subject–verb disagreement across distance — the verb agrees with the nearest noun, not the subject.

    • ❌ "The list of vendors are posted." → ✅ "The list of vendors is posted."
    • Diagnostic: Strip the phrase between subject and verb; do they still agree?

11. "Each / every / none" treated as plural.

    • ❌ "Each of the nodes have a key." → ✅ "Each of the nodes has a key."
    • Diagnostic: Each, every, either, neither, none are singular.

12. "Along with / as well as" mistaken for "and."

    • ❌ "The server, along with its replicas, are backed up." → ✅ "…is backed up."
    • Diagnostic: These phrases don't add to the subject; the verb agrees with the original subject only.

13. Pronoun–antecedent number mismatch.

    • ❌ "Each user must reset their... " (contested) — in strict technical/formal style: "Users must reset their passwords" (pluralize to keep agreement and stay inclusive).
    • Diagnostic: Does the pronoun match its antecedent in number? (Singular they is increasingly accepted — Ch 7 — but pluralizing avoids the dispute entirely.)

14. Inconsistent verb tense.

    • ❌ "The function reads the file and returned an error." → ✅ "…reads the file and returns an error."
    • Diagnostic: Within one description, do the verbs share a tense unless the timeline genuinely shifts?

Parallelism

15. Faulty parallelism in a series.

    • ❌ "…ingests logs, parsing them, and it stores results." → ✅ "…ingests logs, parses them, and stores results."
    • Diagnostic: Do all items in a series share one grammatical form?

16. Non-parallel bullet list.

    • ❌ mixed imperatives, participles, and statements → ✅ all imperative verbs (Run, Apply, Verify).
    • Diagnostic: Does every bullet start with the same part of speech?

17. Unbalanced correlative pair — not only…but also, either…or.

    • ❌ "not only handles X but also it manages Y" → ✅ "not only handles X but also manages Y."
    • Diagnostic: Does the same grammatical form follow both halves of the pair?

18. Illogical comparison.

    • ❌ "The latency is lower than the old API." → ✅ "…lower than that of the old API."
    • Diagnostic: Are the two things compared actually the same kind of thing?

Mechanics-level bloat

19. Expletive padding — there is / there are / it is burying the real subject.

    • ❌ "There are three services that depend on auth." → ✅ "Three services depend on auth."
    • Diagnostic: Does a sentence open with There is/are or It is + noun + that?

20. Wordy connectors — due to the fact that, in order to, has the ability to.

    • ❌ "slipped due to the fact that" → ✅ "slipped because"; "in order to" → "to"; "has the ability to" → "can".
    • Diagnostic: Any phrase containing the fact that, or a multi-word form of a one-word idea (can, to, now, if).

Twenty errors. Most documents you read in the wild contain a dozen of them. Most documents you write contain several, and the only reliable way to catch them is to hunt for one family at a time — modifiers on one pass, pronouns on the next — because trying to catch all twenty in a single read is how they slip through.

📐 Project Checkpoint

In Chapter 3 you ran the clarity checklist on one portfolio paragraph and cut it at least 25%, marking each cut by named defect. Chapter 5 taught you to separate revising (the big moves) from editing (the sentence-level pass). This chapter's increment lives squarely in that editing pass: you'll run a structured error hunt on your portfolio writing, using the 20-error list as your checklist — and you'll do it the way professionals actually do it, one error family at a time.

This chapter's increment: a sentence-level error audit of one full portfolio piece.

1. Pick a complete piece, not a paragraph. Use the most finished draft you have — the blog post, a report section, a README draft. You want enough text (at least 400 words) that the errors have room to hide, because errors hide in volume.

2. Make five passes, each hunting ONE family. This is the heart of the exercise. Do not read for "errors" generally — read five separate times, each time looking only for: - Pass 1 — Modifiers. Check every sentence that opens with a comma'd phrase: is the actor right after the comma? (Errors 1–3.) - Pass 2 — Pronouns. Highlight every this, that, it, they, which. Does each have one clear noun? Force a noun after every orphan this. (Errors 4–6.) - Pass 3 — Sentence boundaries. Find every comma; could both sides stand alone? Find every however / therefore. (Errors 7–9.) - Pass 4 — Agreement & parallelism. Strip long subjects to their skeleton and check the verb; check every list and series for one shape. (Errors 10–18.) - Pass 5 — Mechanics bloat. Hunt there is/are, it is, in order to, the fact that. (Errors 19–20.)

3. Log each fix by error number. Keep a running tally: "Error 4 ×3, Error 7 ×1, Error 19 ×5." After a few documents, your tally reveals your personal error signature — the two or three errors you make most. Knowing yours is worth more than knowing all twenty, because you'll start catching them as you draft.

4. Read the whole piece aloud last. The five targeted passes catch the known errors; reading aloud catches the rhythm problems from §6.7 — the all-long sentence that needs breaking, the all-short stretch that needs subordination.

Keep the annotated draft and your error tally. You'll bring this editing discipline into Chapter 12 (Editing and Revision), where it becomes one stage of a full top-down revision workflow. Next chapter (Word Choice, Tone, and Voice) moves from sentences that are correct to words that are right — because a grammatically perfect sentence can still use the wrong word for its reader and its register.

6.10 Common Mistakes & Practical Considerations

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

Over-correcting into stiffness. Once you learn the rules, there's a temptation to enforce them rigidly — never split an infinitive, never start a sentence with and or but, never end with a preposition. These are not real rules; they're superstitions, several of them invented in the nineteenth century by analogy to Latin. "To boldly go" is fine. Starting a sentence with But is fine and often punchy. Ending with a preposition is fine ("the file you're looking for" beats the contorted "the file for which you are looking"). Don't let rule-knowledge make your prose timid. The rules in this chapter exist to prevent ambiguity and stumbling, not to enforce Victorian etiquette.

Hunting all twenty errors in one pass. You can't. Attention is limited, and looking for everything means catching nothing reliably. The Project Checkpoint's family-by-family method exists because that's how the errors actually get caught. When you read once for "mistakes," your brain re-reads your intention and skips the very errors that are invisible to you. One family per pass.

Confusing a stylistic comma with a comma splice. Not every comma between clause-like things is a splice. "Run the tests, then deploy" is fine because then deploy isn't a complete independent clause with its own subject — it's an imperative continuation. The splice rule is specifically about joining two independent clauses (each with its own subject and a finite verb, each able to stand alone). Learn to recognize what counts as independent, or you'll start inserting semicolons where commas belong.

Treating "rules" that are really conventions as universal. Several items in this chapter are field-dependent. "The data is" vs. "the data are" genuinely splits by discipline. Passive-voice tolerance varies (Chapter 35). Whether you may use I or we in a report depends on your institution. The skill isn't memorizing one answer; it's knowing which questions have a house answer and checking your style guide. When the convention is genuinely contested, be consistent within the document — inconsistency reads as carelessness even when each individual choice is defensible.

Letting grammar-checkers overrule your judgment. Automated checkers are useful for the mechanical errors (a missed agreement, a clear comma splice) but they routinely flag correct constructions and miss meaning-level errors. A checker will happily approve a dangling modifier and then nag you to "simplify" a sentence that's complex for a good reason. Use them as a first-pass net, never as the final authority. You read for meaning; the checker reads for patterns.

Decision framework — when you spot a comma between two clauses:

Frequently Asked Questions

What are the most common grammar errors in technical writing?

The recurring offenders fall into six families: (1) modifier errors — dangling, misplaced, and squinting modifiers that attach an action to the wrong actor; (2) pronoun ambiguity, especially the orphan this with no clear noun behind it; (3) comma splices and run-ons — joining two complete sentences with a comma or with nothing; (4) subject–verb agreement failures across long sentences where subject and verb drift apart; (5) faulty parallelism in lists, series, and comparisons; and (6) mechanics-level bloat like there are…that and due to the fact that. Section 6.9 of this chapter lists all twenty specific errors with corrections and a one-line diagnostic for each.

How do I fix a dangling modifier?

A dangling modifier is an opening phrase whose doer is missing, so the phrase grabs the wrong subject ("After deploying the patch, the latency dropped" — the latency didn't deploy anything). Two fixes: supply the actor right after the comma ("After deploying the patch, we saw the latency drop"), or rewrite the modifier so it no longer implies a human doer ("After the patch deployment, latency dropped"). The diagnostic: after every introductory comma, check that the next word names whoever performs the opening action.

What's the difference between a comma splice and a run-on sentence?

Both errors wrongly fuse two complete sentences. A comma splice joins them with only a comma ("Tests passed, we deployed"); a run-on (or fused sentence) joins them with no punctuation at all ("Tests passed we deployed"). The cause is identical — the writer felt the ideas were related and ran them together — and so are the fixes: a period, a semicolon, a comma plus a coordinating conjunction (so, but, and), subordination (because, when), or a semicolon plus a conjunctive adverb (therefore). The five fixes aren't interchangeable; each expresses a different relationship between the two ideas, so choosing one is a writing decision, not a mechanical one (§6.4).

Why does the word "this" cause so many problems?

Because writers use this to point at the whole idea of the previous sentence or paragraph rather than at one specific noun, leaving the reader to reconstruct the antecedent. The fix is mechanical and reliable: never let this stand alone — put a noun right after it (this combination, this delay, this mismatch). The rule does double duty: it removes the ambiguity for the reader, and it often reveals that you hadn't pinned down exactly what you were referring to. An orphan this is frequently a symptom of unfinished thinking (a callback to Chapter 1).

Should technical sentences be short?

Not uniformly. Short sentences land facts and create emphasis; longer sentences carry relationships, sequences, and qualifications. Prose that is all short reads like a telegram and flattens cause and effect to the same weight; prose that is all long exhausts the reader's working memory. The goal is variety: match sentence length to the weight of the idea, and use a short sentence after several long ones to create emphasis through contrast (§6.7). Chapter 3's "cut words" advice was about removing inert words, not about making every sentence short.

Chapter Summary

Key Takeaways

• Sentence errors are precision failures, not bloat. A sentence can pass every clarity test in Chapter 3 and still be broken — grammatically ambiguous in ways that make the reader stop and re-read.
• Modifiers attach to the nearest noun. A dangling modifier (no actor), a misplaced modifier (wrong neighbor), or a squinting modifier (looks both ways) makes the sentence claim something you didn't mean.
• Every pronoun needs one clear antecedent. The orphan this is the most common error in technical prose — give every this a noun, and prefer repeating a noun over an ambiguous it.
• A comma can't join two sentences. Comma splices and run-ons have five distinct fixes (period, semicolon, comma+FANBOYS, subordination, semicolon+adverb); choosing among them specifies the logical relationship.
• Agreement breaks over distance. Strip the phrase between subject and verb and check that the skeleton agrees; watch each/every/none (singular) and along with (doesn't pluralize).
• Parallel form makes structure visible. Series, lists, correlative pairs, and comparisons must share one grammatical shape.
• Vary your sentences. All-long exhausts; all-short flattens. Use length and structure to guide the reader, and a short sentence after long ones for emphasis.
• Cut mechanics-level bloat. Expletives (there are…that), in order to, and the fact that constructions pad every draft and have clean one-word fixes.

Action Items

1. Bookmark the §6.9 list of 20 errors; use it as a proofreading checklist on your next document.
2. On your next draft, run five targeted passes — one error family per pass (the Project Checkpoint).
3. Keep a tally of which errors you make; learn your personal error signature.
4. Find every orphan this in your current writing and give each one a noun.
5. Read your next important document aloud, slowly, listening for splices and rhythm.

Common Mistakes

• Over-correcting into stiffness (enforcing fake rules like "never split an infinitive").
• Trying to catch all twenty errors in one reading pass instead of one family at a time.
• Treating field conventions (data is/are) as universal rules.
• Letting a grammar-checker overrule your judgment about meaning.

Decision Framework — the one-line version: When a sentence makes you stumble, name the error family (modifier? pronoun? boundary? agreement? parallelism? bloat?), then apply that family's fix. Diagnosis beats feel — a fix you can name is a fix that transfers to the next sentence.

Spaced Review

A few questions reaching back, to strengthen retention.

1. (From Chapter 5) Chapter 5 separated the writing process into five stages — plan, draft, revise, edit, proofread. The error-hunting in this chapter belongs to which stage(s), and why would running it during drafting be a mistake?
2. (From Chapter 4) Chapter 4 argued that structure serves the reader. How is faulty parallelism (§6.6) a structure failure at the sentence level — what does parallel form let the reader see?
3. (Bridging, Chapter 3 → 6) Chapter 3 said to cut wordy sentences, and §6.7 of this chapter warns against prose that is all short. Reconcile these: what exactly was Chapter 3 telling you to cut, and how is that different from making every sentence short?

What's Next

You can now build sentences that are correct — no dangling modifiers, no comma splices, agreement and parallelism intact — and vary them so they read well. But correctness isn't the same as the right word. A grammatically flawless sentence can still pick a word that's too formal for a Slack message, too casual for a journal, or subtly wrong in connotation. Chapter 7 moves from grammar to diction, tone, and voice: choosing the precise word, matching your register to your audience and genre, deciding when to project confidence and when to hedge honestly, and writing in language that includes rather than excludes. If this chapter was about sentences that work, the next is about sentences that sound right — to a specific reader, in a specific situation. Sentences correct; words right.

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