5 exercises — mixing short, medium, and complex sentences: combining choppy sentences and breaking up run-ons in technical documentation.
0 / 5 completed
1 / 5
A developer writes: "The service starts. The service loads config. The service connects to the database. The service listens for requests." Which rewrite best improves sentence variety?
Option D is correct — all three rewrites improve the choppy original by varying sentence structure. Option A uses a compound predicate (four verbs sharing one subject). Option B uses a subordinate temporal clause ("When…"). Option C opens with a participial phrase ("Starting up…") and uses more varied vocabulary (establishes, begins listening). In practice, combine all three techniques across a paragraph rather than repeating one pattern. The original uses four identical short sentences, which creates a list-like drone. Technical writing benefits from sentence variety: mix short declarative sentences (for emphasis) with complex sentences (for relationships) and compound predicates (for parallel actions).
2 / 5
A postmortem reads: "The monitoring system detected the anomaly. However, the alert did not fire. This was because the threshold was misconfigured. The on-call engineer was not paged." Which rewrite is best?
Option B is the strongest. It uses a concessive clause ("Although…") to link cause and effect, an em dash to insert the root cause efficiently, and a participial phrase ("leaving…") to show consequence — three different structures in one sentence. It reads as a single coherent event sequence, not four separate observations. Option A runs all four clauses together with semicolons and conjunctions, creating a run-on. Option C improves the original slightly but uses "But" and "So" — too casual for a postmortem. Option D is formal and correct but uses a passive construction ("was detected") that buries the monitoring system at the end. For postmortems: use varied structures that show the causal chain clearly.
3 / 5
An architecture document contains this passage: "We use Redis for caching. We use PostgreSQL for persistence. We use Kafka for events. We use Elasticsearch for search." Which rewrite demonstrates the best sentence variety for a technical document?
Option B is the best for a technical document. It opens with a meta-sentence ("The stack comprises four data stores") that signals the structure to the reader, then uses a colon-introduced list that avoids repeating the verb pattern. This is a common and effective technique in technical documentation: introduce the category → list the members with their roles. Option A is a compound sentence with a comma-separated list — acceptable but more suitable for prose. Option C turns each sentence passive — creates repetition of "is Xed by" which is awkward. Option D pairs the sentences but still repeats "is used for" four times. When listing parallel items in technical docs, prefer a list structure or colon introduction over repetitive parallel clauses.
4 / 5
Which version of this technical explanation best uses a short sentence for emphasis combined with longer explanatory sentences?
Option C is the best. It uses a medium-length compound sentence to describe the pipeline stages, a second sentence to explain the deploy strategy, and then two short sentences ("Zero downtime. That is the goal.") for emphasis. Short sentences after longer ones create a natural full stop — they signal: this is what matters. Option A packs everything into one unwieldy sentence with a relative clause hanging at the end. Option B does the same and never reaches a natural pause. Option D is a numbered series — useful for step-by-step instructions but feels mechanical in a technical explanation passage. Use short sentences deliberately: one short sentence after two longer ones draws the eye.
5 / 5
A README section reads: "You need to set the environment variables. You need to install the dependencies. You need to run the migration. You need to start the server." Which rewrite best uses varied sentence structure for a setup guide?
Option B is the best for a README setup guide. It groups prerequisites into a subordinate clause ("Before starting…"), combines them ("set… and installed…"), uses a temporal connector for the sequential step ("Once the migration has been executed"), and includes the exact command (`npm start`). This reads as a human explanation, not a robot list. Option A is a single long sentence — grammatically correct but reads like a mental checklist without guidance. Option C improves conciseness but loses context about order and prerequisites. Option D uses a nominal chain ("the migration should be run… the server can be started") — overly formal and harder to scan. Setup guides benefit from: one sentence for prerequisites, a second sentence for the action step, and code inline.