Part VII — Writing for Specific Fields

By now you might suspect that "technical writing" is really one skill wearing many uniforms. This part proves it. The principles don't change between fields — audience, structure, clarity, revision — only the conventions do. An engineer's requirements spec, a programmer's postmortem, a scientist's cover letter, a clinician's note, and a policy brief look nothing alike on the page, yet each is the same underlying discipline aimed at a different reader with a different stake. Learn the principle once, in Parts I and II, and each field becomes a matter of local custom: which voice the methods section takes, which modal verb carries an obligation, which audience can be harmed if you get it wrong.

What makes this part worth your time even outside your own field is that each discipline dramatizes a principle the others share. Engineering shows you that an untestable requirement is a wish, which is just precision made unforgiving. Medicine shows you that ambiguity is a safety hazard, which is clarity with a person's life as the cost of failure. Science shows you that publishing is a negotiation with named humans, which is audience analysis at its most consequential. The field is the costume; the lesson is universal. Read your own chapter for the conventions, and the others for the principle thrown into sharp relief.

By the end of Part VII you will be able to write requirements that are atomic, unambiguous, and testable; separate the work from the person in a code review and a postmortem; match your field's voice and report statistics so a skeptic can check you; write clinical notes and patient material that cannot be misread into harm; and carry one finding up the compression ladder from a full report to a one-page brief for a board.

What's in this part:

  • Chapter 33 — Writing for Engineering: Specs and Requirements — requirements as commitments that will be verified, RFC 2119's SHALL/SHOULD/MAY, normative versus informative, and the traceability spine.
  • Chapter 34 — Writing for Computer Science: Reviews to ADRs — critique the code not the coder, the blameless postmortem, PR descriptions, bug reports, and testable acceptance criteria.
  • Chapter 35 — Writing for Science: Publication Conventions — field voices over a single "science voice," statistical reporting, preprints and open access, and the two letters that decide a paper's fate.
  • Chapter 36 — Writing for Medicine and Healthcare: SOAP notes, patient material at a 6th-to-8th-grade level, teach-back, evidence grading, and instructions with exactly one reading. (Educational only; not medical advice.)
  • Chapter 37 — Writing for Business and Policy: executive summaries, white papers, policy briefs, the one-pager, board memos, and the compression ladder.

These five chapters are mutually independent — read the ones your work demands. Each leans on earlier material: Chapter 34 extends the documentation of Part V and the blameless framing of Chapter 21; Chapter 35 deepens the research paper of Chapter 14; Chapter 36 inherits Chapter 13's Results-versus-Discussion boundary; Chapter 37 carries Chapter 20's executive-summary threshold up a whole ladder. Each track finds its home field here, but the cross-reading is where the part earns its place.

Audience is everything is the spine of this part — the tester and auditor, the frightened on-call engineer, the editor and reviewer, the patient and the regulator, the board member with the least time and the most authority. Clarity is not the enemy of precision governs the engineering spec, where precision is the deliverable, and the scientific statistic, where a number without an effect size isn't a result. Structure serves the reader orders the spec for the verifier, the postmortem for the team, the brief for the decision-maker. And writing is thinking runs underneath: writing a requirement testably, weighing the alternatives in a design doc, and minimizing a bug repro are all ways of doing the thinking the vague version let you skip. Dana Whitfield's churn finding reappears in Chapter 37, carried up to a one-page brief for leadership.

The Communication Portfolio's technical report gains its requirements section in Chapter 33, and its data memo is recompressed for executives in Chapter 37 — the pieces converging toward assembly.

With the fields surveyed, the book steps back to ask what all this skill is for. Part VIII confronts the ethics of clarity — that the better you write, the more harm a wrong message can do — and the long-run practice that keeps a writing life growing.

Chapters in This Part