Case Study 2 — The Draft That Got Worse: Over-Editing and the Diminishing-Returns Trap

A composite, fictional-but-realistic scenario. Raj Patel and the specifics are invented; the failure mode — polishing past the point of improvement, and editing out clarity in the name of "polish" — is one every careful writer eventually falls into.

The situation

Raj Patel is a backend engineer writing the README for an internal service his team owns. He's a conscientious writer — which, this time, is the problem. His Tuesday draft of the overview paragraph is genuinely good:

DRAFT (Tuesday — already clear):

"PaymentGateway handles all outbound payment requests for the billing
system. It retries failed requests automatically and writes every
attempt to the audit log. To use it, call `submit()` with a signed
payment object; the service returns a confirmation ID you can track."

That paragraph passes every test this book teaches: it leads with what the thing does, it's concrete, every sentence earns its place, a stranger could act on it. Raj should have run a proofread and shipped it. Instead, with two more days before the doc was due and a vague feeling that it wasn't "polished enough," he kept editing. This is where it went wrong.

The over-editing spiral

Raj didn't revise — there was nothing structural left to fix. He fiddled, pass after pass, mistaking motion for improvement. Watch the same paragraph degrade.

Wednesday (reaching for "sophistication"):

"PaymentGateway serves as the centralized orchestration layer
responsible for the handling of all outbound payment requests
emanating from the billing subsystem. In the event of a failed
request, automated retry logic is invoked, and a comprehensive record
of each and every attempt is persisted to the audit log."

He's added nouns to sound more formal — "orchestration layer," "in the event of," "is invoked," "is persisted." Every change is a step down the clarity ladder: "handles" became "serves as the centralized orchestration layer responsible for the handling of"; the active "it retries" became the passive "automated retry logic is invoked." The paragraph is now longer, slower, and says less per word — the exact bloat this book exists to fight. He also quietly deleted the most useful sentence (the submit() example) because it "felt too low-level for an overview."

Thursday (churning surface): By Thursday he's swapping "comprehensive" for "exhaustive" and back, moving a comma in and out of "each and every," and rewording the first sentence a third time without changing its meaning. His edits have stopped changing meaning and started churning surface — the precise diminishing-returns signal from §12.7. He is, in the chapter's words, procrastinating in a productive costume.

The peer review that caught it

Thursday afternoon, Raj asks a teammate, Lena, to review. She reads the Tuesday and Thursday versions side by side (he'd kept both in his editor) and gives feedback the §12.5 way — highest-level problem first, specific, kind:

"Honest take: Tuesday's version is better than Thursday's, and it's not close. Thursday reads like a contract — 'centralized orchestration layer responsible for the handling of' is just 'handles' wearing a suit. As a reader who'd actually need this README, the thing I most want is the submit() example you deleted; that's the one sentence that tells me how to use it. My advice: revert to Tuesday, paste the submit() sentence back, run a proofread, and ship. You finished this two days ago — you've been un-finishing it since."

Note what makes Lena's feedback land: she doesn't say "Thursday is bad" (a verdict). She reports her experience as a reader ("the thing I most want is the example you deleted") and prioritizes ruthlessly ("revert, paste, proof, ship"). And Raj — practicing §12.6 — doesn't get defensive or explain what he "meant" by "orchestration layer." He hears the diagnosis (he over-edited), takes it, and reverts.

The fix

Raj goes back to the Tuesday paragraph almost verbatim, restores the deleted example, does one slow proofread, and ships it.

❌ Over-edited (Thursday): "PaymentGateway serves as the centralized orchestration layer responsible for the handling of all outbound payment requests emanating from the billing subsystem. In the event of a failed request, automated retry logic is invoked, and a comprehensive record of each and every attempt is persisted to the audit log."

✅ Shipped (reverted + proofed): "PaymentGateway handles all outbound payment requests for the billing system. It retries failed requests automatically and writes every attempt to the audit log. To use it, call submit() with a signed payment object; the service returns a confirmation ID you can track."

Why the reverted version wins: It's shorter, active, and concrete. "Handles" beats "serves as the centralized orchestration layer responsible for the handling of" by nine words and zero lost meaning. The restored submit() sentence is the most useful line in the paragraph for the reader who actually opens this README. Raj's two extra days of "polish" produced a worse document; the cure was to throw that work away and trust the draft that was already done.

What this case teaches that Case Study 1 didn't

Case Study 1 showed revision working — a real document made genuinely better by descending the hierarchy. This one shows the opposite failure, the one careful writers are prone to: editing past the point of improvement, and confusing "more formal" with "better."

  1. Done is a real state — recognize it. Raj's Tuesday draft was finished. The skill of knowing when to stop is as important as the skill of revising, and harder for conscientious people. When your edits stop changing meaning, you crossed the finish line a while ago.
  2. "Polished" is not "longer and more formal." Most over-editing adds nouns, passives, and packaging in a bid to sound sophisticated. That's the bloat the book fights, not the cure for it. Formal ≠ clear; usually it's the reverse.
  3. The diminishing-returns test is the off-switch. Swapping "comprehensive"/"exhaustive" back and forth is surface churn, not revision. When you catch yourself there, ship.
  4. A second reader breaks the spell. Raj had stared at the paragraph so long he couldn't see it had gotten worse. Lena, cold to it, saw it in one read — the same reason the 24-hour gap works, outsourced to another person.

One sentence to remember: Perfect is the enemy of sent — and past a certain point, "more editing" doesn't mean "better," it means "different and usually worse."