Glossary

Every term this book treats as load-bearing, defined in plain language and pointed back to the chapter that introduces it. Where a concept first appears in one chapter but gets its full treatment in another, the entry says so. Use this as a quick reference; use the Index to find every place a term is used.

A definition that takes a paragraph to say what a sentence could say has failed the book's own test. So these are short on purpose. If you want the why behind the what, the chapter reference is the door.

A

Abstract — A 150–250-word stand-alone miniature of a whole paper or report, mirroring its structure (gap → approach → key result → significance). It must deliver the findings, with numbers, not merely announce that findings exist. (Ch 13, Ch 14)

Acceptance criteria — The specific, testable conditions that define "done" for a feature or user story; the contract for done. Often written as Given-When-Then. (Ch 34)

Acceptance criterion (requirements) — The specific, measurable condition that constitutes a pass for a single requirement. (Ch 33)

Accessibility (as obligation) — Writing so the broadest appropriate audience can reach and understand the document, including readers using assistive technology. An obligation, not a courtesy. (Ch 10, Ch 38)

Accuracy (ethical obligation) — Claiming exactly what the evidence supports — no more and no less. Not merely "no false sentences" but "no false impression." (Ch 38)

Action item — A concrete next step from a meeting or postmortem, with exactly one named owner and a deadline; never "be more careful." (Ch 21, Ch 34)

Active voice — Sentence structure where the subject performs the action ("the team shipped the fix"). The default for clear technical prose. (Ch 3)

Adverse effect — A drug's side effect; the plain-language equivalent used in patient-facing material. (Ch 36)

Agent–action–object — The who-does-what-to-what frame for rebuilding a sentence around a strong verb. The cure for nominalization. (Ch 3)

Analogy — A device that explains an unfamiliar target by mapping it onto a familiar source already in the reader's head, letting them grasp a concept before learning its vocabulary. (Ch 28)

Annotation (portfolio / source) — A short note that interprets rather than labels: for a portfolio piece, two or three sentences naming the audience and the one skill it shows; for a source, a per-source note in your own words. (Ch 15, Ch 40)

Antecedent — The noun a pronoun stands in for. When it's missing or unclear, the pronoun floats. (Ch 6)

APA style — Author–date citation style — (Author, year) — common in the social, behavioral, and many life sciences. (Ch 11)

API documentation — Documentation for an interface other programs call: the contract that lets a developer use it without reading the source code. (Ch 25)

Approach (grant) — The experimental-plan section of a proposal answering will it work? — design, expected outcomes, pitfalls and alternatives, preliminary data. (Ch 17)

Architecture decision record (ADR) — A short (one page or less) record of one significant decision: Context, Decision, Consequences (plus Status). Captures the why that code cannot. (Ch 25)

Architecture diagram — A diagram showing a system's static structure: what the parts are and how they connect. (Ch 32)

Article processing charge (APC) — The fee (roughly $2k–$11k) an author pays for gold open-access publication. (Ch 35)

Assertion–evidence slide — A slide whose title is a full-sentence claim (the one thing to remember) and whose body is a single supporting visual, with almost no bullet text. The book's recommended slide form. (Ch 18, Ch 30)

Assessment vs. diagnosis — In a clinical note, the Assessment is the clinician's reasoning (likelihood, differential, what would change the plan), not just a diagnostic label. (Ch 36)

Assumed step — An action the author performs automatically and never writes down — the single most common defect in instructions and tutorials. It cannot be caught by rereading; only a real beginner reveals it. (Ch 22, Ch 26)

Asynchronous communication — Channels (email, chat) where sender and reader aren't live, as opposed to synchronous channels (call, meeting) used to resolve disagreement. (Ch 19)

Atomic requirement — One requirement per statement; the rule that you split at every "and" joining two independent obligations. (Ch 33)

Attribution — Crediting a source, including for figures and data ("adapted from [source]"). (Ch 11)

Audience analysis — Deciding who the reader is and what they need before drafting. The first move of almost every document. (Ch 2)

Audience profile — The written output of audience analysis (a full K-R-A-C) that drives every later drafting decision. (Ch 2)

Augmentation vs. outsourcing — The test for honest AI use: did the idea originate with you? Augmentation means you thought first and the model helped you express it; outsourcing means the model supplied the substance. (Ch 29)

Author-contribution statement — A statement mapping each author of a paper to their specific roles. (Ch 35)

Axis truncation — Starting a bar-chart axis somewhere other than zero, which distorts proportion because bars encode value by length. A common way to mislead with a chart. (Ch 9)

B

Backward scheduling (thirds rule) — Scheduling a writing project from the deadline backward, reserving roughly the final third for revising and polishing so revision time isn't starved (≈ ⅓ plan, ⅓ draft, ⅓ revise). (Ch 5)

Badge — A small status image (build, version, license) on a README that signals a project is alive and trustworthy. (Ch 25)

Benefit — What a feature does for the reader — the outcome they feel — reached by asking "so what?" of a feature. Audience-dependent. (Ch 20)

Bibliography — A broader end list that may include works consulted but not cited (the Chicago sense), as distinct from a reference list. (Ch 11)

Blameless — A stance that attacks the system that allowed a human error to cause harm, not the human. Not "no accountability" — more accountable, with specific owners and dates. (Ch 21, Ch 34)

Blameless postmortem — An incident analysis whose reasoning targets the system and the conditions that let an error reach production, not the individual. Blameless is not anonymous. (Ch 34)

Blocking vs. non-blocking comment — In code review, a comment that must be addressed before merge (blocking) versus one that need not be (often prefixed nit:). (Ch 34)

BLUF (Bottom Line Up Front) — Lead with the conclusion, recommendation, or request, then give the support. The single most useful structural habit in workplace writing. (Ch 4)

Board memo / board packet — Materials prepared for a board of directors; the key move is separating what requires board action from what is for awareness. (Ch 37)

Bottom-up organization — Presenting information in the order the writer discovered it (chronological, conclusion last) rather than the order the reader needs it. Usually the wrong choice. (Ch 4)

Broader impacts — A proposal's value beyond the immediate science; for NSF, one of two top-level review criteria. Must be concrete and resourced, not boilerplate. (Ch 17)

Budget justification — The narrative in a proposal tying each requested dollar to a specific aim and task. (Ch 17)

Bug report — A written account of a defect that lets a developer reproduce and fix it; its two halves are expected vs. actual behavior, plus reproduction steps. (Ch 34)

C

C4 model — Simon Brown's discipline of drawing a set of architecture diagrams at increasing zoom — Context, Container, Component, Code — rather than one diagram of "the architecture." (Ch 32)

Calibrated language — Matching the strength of a claim's verb ("suggests," "is consistent with," "demonstrates") to the strength of the evidence — once, then stopping. Cuts both over- and under-claiming. (Ch 7, Ch 13, Ch 38)

Calibration (of certainty) — Matching stated certainty to actual evidence; the habit behind calibrated language. (Ch 7)

Cardinality — In an entity–relationship diagram, the one-to-many or many-to-many relationship between entities; the payload of an ER diagram, shown in crow's-foot notation. (Ch 32)

CC (carbon copy) — Email recipients who should see a message for awareness but aren't asked to act. (Ch 19)

Certainty of evidence — In evidence grading, the confidence in an estimate (high to very low); kept separate from how strongly something is recommended. (Ch 36)

Changelog — A curated, human-readable list of notable changes per released version, written for the upgrading user — not a dump of commit messages. (Ch 25)

Channel selection — Choosing email vs. chat vs. call vs. meeting by speed, permanence, and emotional load. Heuristic: talk to decide, write to record. (Ch 19)

Chartjunk — Tufte's term for non-informative visual noise (3-D effects, heavy gridlines, gradients, redundant legends) that obscures or distorts the data. (Ch 9)

Chicago style — A citation style used in the humanities and policy; its footnote form is the signature. (Ch 11)

Citation — A pointer that credits a source and makes a claim verifiable; it does three jobs at once — credibility, traceability, intellectual honesty. (Ch 11)

Citation as argument — Using citations to build a case — sources grouped and contrasted as evidence — rather than to list who did what. (Ch 15)

Clarity — The reader extracts your meaning on the first pass, at full speed, without rereading. Audience-relative, and the opposite of bloat, not of precision. (Ch 3)

Clarity checklist (8 passes) — The book's diagnostic for cutting a sentence to clarity: so-what → empty-phrase sweep → free the verb → voice → concrete → jargon → read aloud → count the words. (Ch 3)

Clean-machine test — Following your own README on a fresh setup that genuinely lacks your context; every stall is a defect. The software version of the beginner test. (Ch 25)

Code documentation — Writing aimed at a programmer — chiefly your future self and the next maintainer — explaining code without forcing them to re-derive it. (Ch 24)

Code review — The practice of a teammate reading a proposed change before it merges, leaving comments line by line. (Ch 34)

Coherence — Whether a whole passage adds up to a single point (the global sense), as distinct from cohesion (the local stitching). (Ch 8)

Cohesion — Whether neighboring sentences connect (the local, sentence-to-sentence stitching that produces "flow"). (Ch 8)

Collaborative writing — Writing a document with a team — dividing the labor, keeping versions straight, enforcing consistency, and merging several hands into one voice. (Ch 23)

Comma splice — Two independent clauses joined by only a comma. One of the twenty common sentence errors. (Ch 6)

Comment (code) — Internal documentation explaining the why of a line or block to someone reading the implementation. (Ch 24)

Common knowledge — Facts widely known and uncontested within your audience; they need no citation. The boundary is audience-relative. (Ch 11)

Compliance documentation — Documentation demonstrating that a product meets an external standard, mapping each standard clause to its evidence. (Ch 33)

Compression ladder — The elevator pitch, one-pager, executive summary, and full report seen as one piece of work at four levels of compression, each for a reader with different time and need to verify. (Ch 37)

Concision — Using no more words than the meaning requires. Clarity's twin. (Ch 3)

Confidence interval (CI) — A reported range that gives an effect and its uncertainty in real units, e.g., 95% CI [low, high]. (Ch 35)

Conflict of interest disclosure — A plain statement, placed where the reader will see it, of any interest (such as funding) that could shape the work. (Ch 38)

Conjunctive adverb — A connector like however, therefore, consequently; it needs a semicolon, not a comma, to join two clauses. (Ch 6)

Connotation — The feeling, judgment, and association a word carries beyond its literal meaning. (Ch 7)

Consent agenda — Routine board items approved in a single vote without discussion, so meeting time goes to real decisions. (Ch 37)

Context window — The limited budget of text a language model can hold at once; it knows only what's on the screen. (Ch 29)

Coordinating conjunction (FANBOYS) — for, and, nor, but, or, yet, so; the words that can join two independent clauses with a comma. (Ch 6)

Corporate no-voice — Faceless, hedged, abstracted prose that could be written by anyone about anything. (Ch 7)

Corrective action — A concrete change in an incident report that prevents recurrence, each with one named owner and a due date. (Ch 21)

Corresponding author — The author who manages a paper's submission, communicates with the editor, and remains the contact; carries an extra duty of care. (Ch 35)

Cover letter (to an editor) — A persuasive note that makes the venue-fit and significance case for a paper, getting it past the editor's desk. (Ch 35)

CRediT taxonomy — A standardized set of fourteen contributor roles (Conceptualization, Methodology, Investigation, and so on) used in author-contribution statements. (Ch 35)

Critique the code, not the person — The core code-review discipline: describe what the code does, not what the author failed to do. (Ch 34)

Curation — Selecting which portfolio pieces are in or out for a specific reader. A focused five beats a padded seven. (Ch 40)

Curiosity gap — The gap between what a reader knows and what they sense they're about to find out; a hook opens it, the piece closes it. (Ch 28)

Curse of knowledge — Once you understand something, you can't imagine not understanding it, so you overestimate your writing's clarity. Introduced in Ch 1; full treatment in Ch 2. (Ch 2)

Curse of the plausible — The better AI-generated text sounds, the harder a wrong fact is to catch; fluency camouflages error. (Ch 29)

D

Dangling modifier — An introductory phrase whose implied actor is absent, so it grammatically attaches to the wrong subject ("Walking in, the room was dark"). (Ch 6)

Dangling transition — A connector like "This means…" that points at no specific referent; the paragraph-seam version of the orphan "this." (Ch 8)

Dashboard text — The writing in a dashboard's titles, labels, and tooltips that interprets the numbers for a glancing viewer. (Ch 27)

Data-analysis memo — A short written answer to a question of the data, addressed to someone who must act; four parts — question, findings, recommendation, method. (Ch 27)

Data-availability statement — A statement of where a study's underlying data and materials can be found. (Ch 35)

Data-ink ratio — Tufte's principle: maximize the share of a chart's total ink that represents actual data; delete the rest. (Ch 9)

Define-on-first-use — Defining a term you're keeping the first time it appears, inline. (Ch 2)

Definition of done — The team-wide conditions any piece of work must meet before it's finished (tests, review, docs, deploy). (Ch 34)

Deliberate practice — Focused practice aimed at a specific weakness, with a clear goal and feedback on whether you hit it — as opposed to mere high-volume experience that just rehearses current habits. (Ch 39)

Denotation — A word's literal, definitional meaning. (Ch 7)

Design document — A document that says how a system will work and why; its most valuable, most-skipped section is "alternatives considered." (Ch 33, Ch 34)

Desk reject — An editor rejecting a paper without sending it to review, usually on fit, significance, or presentation. (Ch 14, Ch 35)

Developmental feedback — Feedback aimed at the highest-level problems (content and structure), given before sentence-level notes. (Ch 12)

Diagram — A sentence in a visual language: a graph of nodes and edges whose job is to make one idea about a shape, flow, or interaction unmissable — not to be complete. (Ch 32)

Diagrams-as-code — Authoring diagrams as text (for example, in Mermaid) so they live in version control, diff in pull requests, and resist drift. (Ch 32)

Diátaxis — Daniele Procida's framework sorting documentation into four modes — tutorial, how-to, reference, explanation — along two axes; mixing modes in one document degrades all of them. (Ch 26)

Direct quotation — A source's exact words in quotation marks, cited; reserved for when the exact wording matters. (Ch 11)

Disclosure (AI) — Stating AI use according to your context's norm (usually required in academic work, usually not in the workplace, increasingly required by journals). (Ch 29)

DOI (digital object identifier) — A persistent identifier for a source that a reference manager captures — and can get wrong, so verify it. (Ch 11)

Doc drift / stale comment — A comment the code has outgrown, so it now lies. Worse than no comment at all. (Ch 24)

Document owner / single-threaded owner — The one person responsible for a collaborative document reading as though one person wrote it; the owner of the seams. (Ch 23)

Duty of care — The reasonable care a writer owes the readers who will rely on a document (a pilot, a patient, a user, the public) — not only obedience to whoever assigned it. (Ch 38)

E

Editing — Sentence- and word-level work — clarity, concision, grammar, tone. It comes after revision and changes how each sentence reads. (Ch 5, Ch 12)

Editing hierarchy — The six-level, top-down order of revision: content → structure → paragraphs → sentences → words → proofreading. Descend it; never start at the bottom. (Ch 12)

Editorializing — Smuggling judgment, interpretation, or causal claims into what should be a neutral Results report. The three tells: judgment adjectives, causal verbs, and "as expected." (Ch 13)

Effect size — The magnitude of an effect (Cohen's d, r, an odds ratio, and so on); answers "is it big?" as opposed to the p-value's "is it detectable?" (Ch 35)

Elegant variation — Using synonyms for one concept to avoid repetition. A virtue in literary prose; a bug in technical writing, where one term per concept rules. (Ch 7)

Elevator pitch — A roughly 60-second spoken summary — problem, what you did, key result with the number, why it matters — used at a poster or to open a conversation. (Ch 18)

Empty phrase / empty opener — Padding that asserts nothing ("it is important to note that," "there are several factors that"). Cut it. (Ch 3)

Endpoint — A single callable operation of a web API (for example, POST /users). (Ch 25)

Engineering notebook — A contemporaneous, dated record of what was done, observed, and decided, and why — honest about dead ends; carries legal and patent weight. (Ch 33)

Entity–relationship (ER) diagram — A diagram showing the shape of data: entities, key attributes, and the cardinality between them. (Ch 32)

Epistemic modality — The grammatical and lexical resources that mark how committed a writer is to a claim's truth (the linguistics behind hedging). (Ch 7)

Euphemism — A mild or indirect substitute for a blunt word, used to soften or hide a fact ("rightsizing" for layoffs). (Ch 7)

Evidence grading / GRADE — A system (Grading of Recommendations Assessment, Development, and Evaluation) that separates the certainty of the evidence from the strength of the recommendation. (Ch 36)

Exception-based reporting — Spending detail only where there's a deviation and compressing on-track items to one line; allocate the reader's attention by their need to act, not by how much work was done. (Ch 21)

Executive summary — The stand-alone opening of a long document that carries the whole decision (situation, ask, justification, cost, next step). For most readers it is the document. (Ch 13, Ch 20, Ch 37)

Expected vs. actual behavior — The two halves of a bug report; a bug is the gap between them. (Ch 34)

Explanation (Diátaxis mode) — Understanding-oriented documentation: the rationale, trade-offs, and background, read away from the keyboard. (Ch 26)

Explanation effect (self-explanation effect) — Producing a full explanation, rather than rereading, exposes the gaps in your understanding and improves it. The everyday version is rubber-duck debugging. (Ch 1)

Expletive construction — There is / there are / it is used as an empty subject that delays the real one. Usually cuttable. (Ch 6)

Exploratory vs. explanatory graphics — Charts made to find an insight (for the analyst) versus charts made to show it (for the reader). Don't publish the former. (Ch 9)

F

Faulty parallelism — Items in a series, list, or comparison that don't share the same grammatical form. (Ch 6)

Feature — A fact about a solution — what it is or has ("256-bit encryption") — as opposed to a benefit. (Ch 20)

Feasibility study — A decision document comparing options against criteria (including a "do nothing" baseline) and ending in a recommendation. (Ch 21)

Feedback loop — Getting a draft reviewed early enough — after revising — that you can still act on the feedback; or the self-built infrastructure (a trusted reader, a community) that supplies the correction signal once an instructor is gone. (Ch 5, Ch 39)

Few-shot example — One or two samples of a target style or format placed in a prompt; steers a model's output more reliably than describing the style in words. (Ch 29)

Fiduciary duty — A board's legal obligation to act in the organization's best interest; it makes a buried material risk a governance failure, not just a writing failure. (Ch 37)

Figure — Any visual showing relationships in data (a chart, graph, plot, or diagram), as opposed to a table. (Ch 9)

Filler words — "Um, uh, like, you know, basically" — reflexive floor-holders that erode credibility, cured by a deliberate pause rather than mid-talk self-monitoring. (Ch 31)

Finding vs. observation — An observation is what the data says; it becomes a finding (a conclusion) only when it reaches a recommendation. (Ch 27)

Flinch test — The reader's near-instant (about half a second) judgment, before reading a word, of whether engaging with a page will be painful. (Ch 10)

Flowchart — A diagram showing a process with decisions and branches; right when the branching is the message, wrong for linear steps with no decisions. (Ch 32)

Footnote — A source or commentary note at the bottom of the page tied to a superscript number; the Chicago notes-and-bibliography signature. (Ch 11)

Forecasting statement — An early sentence that names what's coming and in what order. A form of signposting. (Ch 4)

Frankenstein document — A multi-author document assembled from parts that each work alone but were never meant to live together, stitched at visible seams (mismatched voice, terminology, structure). (Ch 23)

Front door — The framing of a README — or a portfolio's landing intro — as the first and possibly only thing a visitor reads before deciding whether to go further. (Ch 25, Ch 40)

Functional requirement — A statement of what a system does (a behavior), as opposed to a quality it must have. (Ch 33)

G

The gap — The specific thing a field doesn't yet know, can't do, or got wrong, which makes a contribution necessary; established by the literature review. (Ch 14, Ch 15, Ch 16)

General audience / the unobligated reader — A reader who can leave at any second at no cost and owes you nothing; less specialized, not less intelligent, and always a specific slice, not "everyone." (Ch 28)

Generative AI — Tools that produce content (text and more) by predicting likely continuations one piece at a time. (Ch 29)

Given-new contract — Open each sentence with given (familiar) information and end with the new; the old-to-new flow the reader expects. (Ch 8)

Given-When-Then — A structure for a testable acceptance criterion: context (Given), trigger (When), required outcome (Then). (Ch 34)

Git for docs — Using version-control software (git) to manage a document's history, branches, and merges, the way developers manage code. (Ch 23)

Global revision — The top two levels of the editing hierarchy — content and structure — also called revision proper. (Ch 12)

Gold / green / diamond open access — Gold = free to read, author pays a fee; green = author self-archives a version for free; diamond (or platinum) = free to read and free to publish. (Ch 35)

Growth narrative / portfolio cover letter — A half-to-one-page letter, written last, that shows a writer's growth from their Chapter-1 charter to now with checkable evidence rather than claiming it. (Ch 40)

H

Hallucination — A confident, fluent, fabricated statement from an AI model (an invented statistic, a misattributed quote, a non-existent citation). Not a bug — the model producing plausible text where the plausible answer is false. (Ch 29)

Happy path — The case where everything goes right; what a tutorial teaches, deferring edge cases and error handling to how-to guides. (Ch 26)

Hazard entry — A row in safety documentation: Hazard, Cause, Effect, Severity/Likelihood, Control (as a verifiable requirement traced to a test), Residual risk. (Ch 33)

Headline number — The single most important number in a data write-up, led with rather than buried. (Ch 27)

Health literacy — Writing health information so people can find, understand, and use it; the guideline is roughly a sixth-to-eighth-grade reading level for patient material. (Ch 36)

Hedging — Language that signals uncertainty or qualification (may, suggests, appears, tends to). A tool, not a weakness — used to calibrate certainty. (Ch 7)

House style — A team's documented choices about terminology, formatting, and usage that keep a document consistent across authors. (Ch 23)

How-to guide (task-oriented) — A document for a competent practitioner that solves exactly one specific task, assumes the basics, and explains almost nothing. (Ch 26)

The hourglass — A report or paper's shape: a broad Introduction narrowing to specific Methods and Results (the waist), then widening again in the Discussion. (Ch 13, Ch 14)

Hypothesis — A falsifiable prediction — one a result must be able to refute. (Ch 14)

I

Identity-first language — Phrasing like "autistic person" or "Deaf person" that puts the identity before the person. Community-dependent; the counterpart to person-first language. (Ch 7)

IEEE style — Numbered citation style — [1], in order of appearance — common in engineering and computer science. (Ch 11)

Illogical comparison — Comparing two things of different kinds (a number to a system, one company's revenue to another company). (Ch 6)

IMRaD — Introduction, Methods, Results, and Discussion: the four-part convention answering why / what I did / what I found / what it means. A family of conventions, not one rigid template. (Ch 13)

Inclusive language — Word choice that avoids excluding or stereotyping readers by identity; usually also more precise. (Ch 7)

Inclusivity (ethical obligation) — Language that doesn't unnecessarily exclude readers through gendered defaults, "normal/layman," ableist idioms, or assumed cultural defaults. (Ch 38)

Incident report — A report of something that went wrong, in five parts: Summary, Timeline, Root cause, Impact, Corrective actions. (Ch 21)

Indication / contraindication — What a drug is for / who must not take it. (Ch 36)

Informative header — A heading that states the content or claim of a section, not merely its form ("What the test found," not "Results"). (Ch 4)

Information foraging — The model of readers as foragers hunting "information scent" through a document rather than reading it linearly. (Ch 4)

Information hierarchy — The nested tree of sections and subsections, signaled by heading levels. (Ch 4)

Informed consent — The consent document — a record that supports but does not replace the consent conversation. (Ch 36)

Inner critic — The judging voice that evaluates each sentence as you write it; essential while revising and editing, poison while drafting. (Ch 5)

Institutional / contextual knowledge — Everything specific to your situation, project, and audience that lives nowhere in a model's training data; the AI failure no bigger model fixes. (Ch 29)

Instructions — Text that directs a reader to perform a task, as opposed to describing it; a tool operated one action at a time. (Ch 22)

Instructions for Use (IFU) — The regulated instruction document for a device, often patient-facing and regulatory at once. (Ch 36)

Integration pass — The deliberate editing pass that merges sections by different authors into one consistent voice. The heart of collaborative writing. (Ch 23)

Intention-revealing name — A name that states what a thing is for (days_until_expiry, not d); a comment that can't drift. (Ch 24)

In-text citation — A source reference inside the running text ([4] or (Author, 2013)), as opposed to a footnote. (Ch 11)

Inverted pyramid — Putting the most important information at the top and narrowing to detail — the structure of news writing and of most workplace documents. (Ch 4)

J

Jargon — Specialized vocabulary that is precision when the audience shares it and a barrier when they don't. Audience-relative, not inherently bad. (Ch 2, Ch 3)

Jargon budget — A hard ceiling of two or three technical terms per general-audience article, enforced mechanically (circle, count, cut) because fluency makes jargon invisible. (Ch 28)

JSDoc — JavaScript's docstring convention: a /** */ block with @param, @returns, and @throws tags and types in braces. (Ch 24)

Journal vs. conference — A journal is an archival venue with multi-round review (the permanent record); a conference has a single concentrated review round and hard deadlines, and is often the primary venue in CS. (Ch 14)

K

K-R-A-C framework — The four audience variables to settle before drafting: Knowledge, Role/goal, Action, Context. (Ch 2)

Knowledge level (three dials) — The three components of a reader's knowledge to calibrate separately: domain knowledge, jargon fluency, and context knowledge. (Ch 2)

Known-new chaining — Linking sentences so each one's new information becomes the next one's given — a chain of handoffs. (Ch 8)

L

Lede / nut graf — The lede is the opening hook ("don't bury the lede"); the nut graf is the short orienting passage just after it that says why the story matters and what it's about. (Ch 28)

Level of abstraction — The single zoom level a diagram commits to; mixing levels (infrastructure, application, code) in one diagram is the deadliest architecture-diagram mistake. (Ch 32)

Lie of omission — Leaving out a fact that would change the reader's mind, so every sentence survives a fact-check while the whole document misleads. (Ch 38)

Lightning talk — A roughly five-minute, five-slide talk that selects one idea rather than compressing a long talk. (Ch 18)

Limitations — An honest statement of what a study can not conclude (sample size, untested conditions, confounds). Stating them makes a reader trust you more. (Ch 13, Ch 38)

Literature review — A document that argues from many sources toward a claim about the state of knowledge and a gap — not a catalog of sources. (Ch 15)

Literature-review chapter — The thesis-scale synthesis chapter; it fails by including too much (source-by-source). (Ch 16)

Local editing — The middle and lower levels of the editing hierarchy — paragraphs, sentences, words — also called editing. (Ch 12)

M

Magic number — A bare numeric or string literal in code whose meaning isn't obvious; fix it by naming the what and commenting the why. (Ch 24)

MAY / OPTIONAL — In RFC 2119, a keyword marking something truly optional; omitting it is still conformant. (Ch 33)

Meeting minutes — A record of outcomes — decisions, action items, owners, deadlines — not a transcript of the conversation. (Ch 21)

Mermaid — A diagrams-as-code format, written as text in fenced code blocks, that this book's toolchain renders. (Ch 32)

Methods — The IMRaD section answering what you did; the standard is that a competent peer could reproduce the work from the text alone. (Ch 13)

Minimal reproducible example (MRE) — The smallest self-contained code or steps that reliably trigger a bug; building one is itself debugging. (Ch 34)

Misplaced modifier — A word or phrase sitting next to the wrong target (the classic case is a stray only). (Ch 6)

Mode mixing — One document trying to be two or more Diátaxis modes at once — too slow for the expert and too overwhelming for the beginner. The fix is to split, not rewrite. (Ch 26)

Mosaic plagiarism — Stitching borrowed phrasing from several sources into a paragraph, with citations sprinkled but language borrowed throughout. (Ch 11)

N

Narrative review — A judgment-selected, thematically organized, argumentative literature review; the usual case for paper introductions, theses, and grant backgrounds. (Ch 15)

Narrative structure — The hook → journey → payoff story shape that replaces IMRaD for a general reader who can't be assumed to finish. (Ch 28)

Nit — A conventional nit: prefix on a code-review comment marking it optional and take-it-or-leave-it (usually style or taste). (Ch 34)

Nominalization — A verb or adjective frozen into a noun ("decide" → "decision"), which drags in a weak prop verb and hides the action. (Ch 3)

Non-functional requirement — A quality a system must have — performance, security, reliability, usability (the "-ilities") — as opposed to a behavior. (Ch 33)

Normative vs. informative — In a specification, normative text is the binding requirements; informative text is explanation, rationale, and examples. Keep them visibly separate. (Ch 33)

O

Observation → interpretation → recommendation ladder — Three levels of a data claim: what the data says (Level 1), what it means (Level 2), what to do (Level 3). Only Level 3 is actionable. (Ch 27)

OCAR — Opening, Challenge, Action, Resolution: a narrative arc for a document meant to be read straight through. (Ch 4)

One action per step — The rule that each numbered instruction contains a single performable action; the test is whether the reader would glance back between two actions. (Ch 22)

One-pager — Everything a decision-maker needs on a single page, readable in about sixty seconds — re-conceived around the decision, not a shrunk report. (Ch 37)

One point per slide — Every slide makes exactly one claim or answers one question; if the title needs an "and," split the slide. (Ch 30)

Open access (OA) — A published paper being free to read. Not inherently predatory; a fee alone is not the tell. (Ch 14, Ch 35)

Options analysis — The comparison at the core of a business case: realistic paths (including do-nothing) scored on the same axes. (Ch 20)

Original contribution — New, defensible knowledge (a method, result, dataset, synthesis, or refutation) you can state in one sentence; the bar a thesis must clear. (Ch 16)

Orphan "this" — A bare pronoun this with no single clear antecedent. A frequent symptom of unfinished thinking. (Ch 6)

Outline — A list of points to be made, in reader order, built before prose so the structure can be rearranged cheaply. (Ch 5)

Overclaiming / overstatement — Stretching an interpretation beyond what the evidence supports; at bottom a calibration failure. (Ch 13, Ch 38)

P

Paragraph (as unit of thought) — One idea developed across several sentences; the basic unit of thought, as the sentence is the unit of grammar. (Ch 8)

Paragraph unity — The principle that a paragraph holds exactly one idea and every sentence serves the topic sentence. (Ch 8)

Parallel structure (document level) — Giving comparable parts of a document the same shape so the scanning reader learns the pattern once. (Ch 4)

Paraphrase — Restating a source's idea in your own words and structure, with a citation; the default in technical writing. (Ch 11)

Passive voice — Sentence structure where the subject receives the action (be-verb + past participle). Right when the actor is unknown or irrelevant, in methods, and for given-new flow; otherwise a last resort. (Ch 3, Ch 35)

Patchwriting — Keeping a source's structure and swapping in synonyms; plagiarism even with a citation, even without intent. (Ch 11)

Payback period — How long until an investment recovers its cost ("a 14-month payback"). A favorite executive anchor. (Ch 20)

Peer review — Evaluation by field experts before publication, or a teammate's feedback on a draft; the cure for the curse of knowledge on your own work. Comes in single-blind, double-blind, and open forms. (Ch 12, Ch 14)

PEP 257 — Python's official docstring convention (triple quotes, a one-line summary, a blank line, then elaboration). (Ch 24)

Performance order — Presenting instructions in the exact order the reader does the task, with prerequisites and warnings before the steps that need them. (Ch 22)

Person-first language — Phrasing like "person with autism" or "person who uses a wheelchair" that puts the person before the condition. Community-dependent. (Ch 7)

Persuasion vs. spin — Persuasion gives the reader what they need to judge, including costs and risks; spin withholds what would make a reasonable person disagree. The tell is "hoping they won't notice." (Ch 38)

The pitch — A short email proposing a piece to an editor before writing it: it opens with the hook, names a publication-specific angle, and makes a dated ask. (Ch 28)

Policy brief — A short (two-to-four-page) document translating research into an actionable recommendation for a non-expert decision-maker. Its failure mode is summarizing research instead of recommending. (Ch 37)

Postmortem — A written analysis of an incident: what went wrong, why, and how to prevent recurrence. (Ch 34)

Poster hierarchy — The bold, vertical version of document hierarchy on a research poster: finding-as-title, one dominant figure, short text chunks, white space, big fonts. (Ch 18)

Predatory journal — An exploitative venue that charges fees for little or no real review; tells include unsolicited flattery, guaranteed fast acceptance, and fake metrics. (Ch 14)

Preliminary data — Pilot results included in a proposal to show a claim isn't a fishing expedition, placed where they de-risk the riskiest assertion. (Ch 17)

Preprint — A complete manuscript posted publicly before or during peer review (on arXiv, bioRxiv, and the like); about timing, and not peer-reviewed, so it must be labeled. (Ch 14, Ch 35)

Primary vs. secondary audience — The direct reader versus anyone else who might read the document (forwarders, bosses, future maintainers). (Ch 2)

Problem–solution structure — A persuasive order that establishes the pain before the cure (Situation → Complication → Resolution); a solution offered before its problem has no demand. (Ch 20)

Procedure — An ordered set of steps to accomplish a task. (Ch 22)

Progress report — A report answering "are we on track, and what do you need from me?" — built on Planned / Done / Next / Blocking. (Ch 21)

Proofreading — The final surface pass for broken things — typos, formatting, wrong numbers, broken links. It removes blemishes; it does not improve a document. (Ch 5, Ch 12)

Proposal — A persuasion document seeking approval for a plan ("will you let us do this?"), with standard parts: problem, solution, approach, timeline, budget, qualifications, risks, the ask. (Ch 20)

Prompt / prompt engineering — The instruction given to a model; prompt engineering is the craft of writing prompts that get useful output — mostly the craft of writing a good brief. (Ch 29)

Pronoun ambiguity — A pronoun (especially a bare this) with no single clear antecedent. (Ch 6)

Pull request (PR) — A bundle of proposed code changes for merging, accompanied by a written description that supplies the intent and verification the diff can't. (Ch 34)

Purpose (four modes) — The four reasons to write: inform, persuade, instruct, record. (Ch 2)

Purpose statement — One sentence — "After reading this, [reader] will ___" — naming the reader, the goal, and ideally the argument; the document's include/cut test. (Ch 5)

P-value — The probability of a result this extreme if there were no real effect; reported exact and with no leading zero (p = .045). (Ch 35)

Q

Q&A bridging — Answering a question you can't fully answer by stating the limit, connecting it to what you do know, and offering a reasoned next step. Beats bluffing, which expert audiences detect. (Ch 18, Ch 31)

Quick-start — A README's most important section: the shortest path from nothing to a working result. (Ch 25)

R

RACI — A responsibility-assignment scheme (Responsible, Accountable, Consulted, Informed) for clarifying who does what in a collaborative document or review. (Ch 23)

RAG status — A Red / Amber / Green health indicator: Green = on track; Amber = at risk but recoverable; Red = needs a decision or resources now. (Ch 21)

Range (the meta-skill) — The ability to read a situation and match the form to it; what a portfolio's pieces together prove that any one cannot. (Ch 40)

Reading context — How the reader will read: skim or study, screen or print, friendly or hostile, now or later. (Ch 2)

Reading path — The obvious order (numbers, arrows, or a strong column flow) that tells a poster or diagram reader where to start and where to go next. (Ch 18)

Reading as a writer — Reading for craft — how a piece works — rather than only for content. (Ch 39)

Read-aloud technique — Reading a draft aloud (or via text-to-speech) so the ear catches what the eye skips. (Ch 12)

Read-backwards technique — Reading last sentence first to destroy narrative flow and inspect each sentence in isolation; a proofreading move. (Ch 12)

README — The file a code host displays on a project's landing page; the project's front door. (Ch 25)

Reasonable-reader standard — Judging accuracy, transparency, and spin by what a competent member of the actual audience would need and would conclude. (Ch 38)

Redundant figure — A figure that duplicates the prose or a table; it violates the rule that every element earns its place. (Ch 9)

Redundant modifier — An adjective that repeats what its noun already contains ("advance planning," "end result"). (Ch 3)

Reference documentation — Information-oriented documentation consulted for one specific fact, not read front to back. (Ch 26)

Reference list — The end list containing only the sources actually cited (one-to-one with the in-text citations). (Ch 11)

Reference manager — Software (Zotero, Mendeley) that stores sources and generates formatted citations — whose output you must still verify. (Ch 11)

Register — The level of formality a piece adopts (formal, neutral, informal), set by audience and genre. Formal does not mean bloated. (Ch 7)

Release notes — The user-facing announcement of what's new, changed, and fixed in a version; broader and more communicative than a changelog. (Ch 34)

Replicability / reproducibility — The foundation of empirical credibility: a result no one can reproduce is not yet a result. In a methodology, the standard that every choice affecting the result is stated. (Ch 13, Ch 16)

Reproduction steps — Exact, ideally runnable steps that trigger a bug. (Ch 34)

Request / response — What a caller sends an API and what the API returns, documented as actual JSON plus a status code. (Ch 25)

Requirement — A statement of something a system must do or a quality it must have; a commitment that will be verified. (Ch 33)

Requirement ID — A unique, stable identifier (REQ-PERF-001) that threads a requirement through design, test, and report. (Ch 33)

Response to reviewers — A point-by-point reply to peer-review comments; gracious, firm, every comment addressed, concede first and defend narrowly. (Ch 14, Ch 35)

Reverse outline — An outline made from a finished draft — one line per paragraph stating what it does — used to diagnose structure. (Ch 4, Ch 12)

Review / approval workflow — The defined process by which a collaborative document is reviewed and signed off, with reviewers and approvers named. (Ch 23)

Revising — Re-seeing the whole document — the big moves of cutting, reordering, and filling gaps. It changes what is said and how it's organized, and it comes before editing. (Ch 5, Ch 12)

Revision (as the work) — The principle that a document becomes good in revision, not in the first draft; the first draft exists to be changed. (Ch 5, Ch 12)

RFC 2119 — The real IETF document (1997) defining requirement-level keywords (MUST, SHALL, SHOULD, MAY) for specifications. (Ch 33)

RFP (Request for Proposal) — A client's formal solicitation, usually with a required format and a scoring rubric; an external proposal must follow it exactly. (Ch 20)

Risk–mitigation — A two-column structure pairing real, material risks with concrete controls; naming risks proactively builds trust. (Ch 20)

Roadmap (talk) — A single spoken sentence after the hook that names a talk's shape, giving the audience a container for what's coming. (Ch 31)

Role prompting — Assigning a model a role ("you're a senior engineer") to steer register and stance — not to confer real expertise. (Ch 29)

Root cause — The underlying system condition that allowed an incident, reached by asking "why was it possible?" past the proximate trigger. (Ch 21, Ch 34)

ROI (return on investment) — The value returned relative to the cost; the core justification in a business case. (Ch 20)

Rubber-duck debugging — Explaining your code aloud (to a rubber duck, if need be) to find the bug; the everyday form of the explanation effect. (Ch 1)

Run-on / fused sentence — Two independent clauses joined with no punctuation at all. (Ch 6)

S

Saturation — The point where new sources stop adding new themes to a synthesis matrix; the signal to stop reading. (Ch 15)

Scanning — How readers actually consume technical documents: hunting for the parts they need, not reading linearly. (Ch 4)

Scope (decision size) — The size of a decision; a document's depth should match it (a paragraph for a $4K call, the full treatment for a $4M one). (Ch 20)

Scope boundary — The explicit written sentence of what a thesis or project is not about; a proposal's single most protective sentence. (Ch 16)

Scope creep — The slow, unnoticed drift of a project away from its governing claim, one reasonable-sounding addition at a time. (Ch 16)

Scoping review — A review that uses a documented search to map a field's extent and gaps rather than answer a narrow question. (Ch 15)

SCQA — Situation, Complication, Question, Answer: Minto's structure for opening a document. (Ch 4)

Science communication — Explaining a technical idea to people who don't share your training and didn't ask for a lecture. (Ch 28)

Self-documenting code — Code clear enough — through names, constants, and structure — that the what needs no comment. It retires what-comments so why-comments stand out; it is not "no comments." (Ch 24)

Self-plagiarism — Reusing your own prior submitted or published work as if it were new, without disclosure. (Ch 11)

Sentence variety — Deliberate variation of sentence length and structure for rhythm and emphasis. (Ch 6)

Sequence diagram — A diagram showing interactions ordered in time (top to bottom), with solid arrows for calls and dashed for returns. (Ch 32)

Shared decision-making — Clinician and patient deciding together; the conversation that consent writing serves. (Ch 36)

SHALL / MUST / REQUIRED — In RFC 2119, keywords marking an absolute, mandatory requirement (SHALL and MUST are synonyms). (Ch 33)

Shitty first draft (SFD) — Anne Lamott's term for the deliberate permission to write a bad, complete first draft as raw material to revise. (Ch 5)

SHOULD / RECOMMENDED — In RFC 2119, a keyword marking a recommendation; deviate only with a deliberate, documented reason. (Ch 33)

Signal word — The labeled severity term that prefixes a safety message — Danger, Warning, Caution, Note (the ANSI Z535 hierarchy). (Ch 22)

Signposting — Sentences and devices that tell the reader what's coming, where they are, and how the parts connect. (Ch 4)

Small multiples — A grid of small charts sharing axes, used for comparison (Tufte). (Ch 9)

Smart-friend test — Explaining something as if aloud to a sharp non-specialist, then keeping whatever you'd naturally simplify. (Ch 2)

SOAP note — A clinical documentation format with a fixed order: Subjective (what the patient reports), Objective (what's measured), Assessment (the reasoning), Plan (the action). (Ch 36)

"So what?" test — Asking of every sentence, number, or section whether it delivers a fact, supports a claim, or moves toward a decision; if not, cut it. (Ch 3, Ch 27)

Speaker notes — What the presenter says per slide — the argument and the details the visual doesn't show. The slide is the aid; the notes are the talk. (Ch 18, Ch 31)

Specification (spec) — The organized collection of requirements for a system. (Ch 33)

Specific Aims — The one-page summary (the NIH term) that is the single most important page of a proposal, stating the problem, gap, hypothesis, aims, and payoff. (Ch 17)

Squinting modifier — An adverb sitting between two clauses it could modify either way. (Ch 6)

Standalone test — Stripping away the rest of a document to ask whether the reader can still decide from the summary alone, and whether they know the ask. (Ch 20, Ch 37)

Standard operating procedure (SOP) — A procedure with scaffolding (purpose, scope, roles, prerequisites, revision record) whose defining discipline is making any two people perform the task identically. (Ch 22)

Status code — The HTTP result code an API returns (201 Created, 409 Conflict). (Ch 25)

Status update — A roll-up of many workstreams for someone scanning the whole at a glance; built on RAG plus exception-based detail. Higher altitude than a progress report. (Ch 21)

Strength of recommendation — In evidence grading, how forcefully something is advised (strong vs. conditional), weighing evidence against benefits, harms, costs, and values. (Ch 36)

Stress position — The end of a sentence, where emphasis falls and the reader expects the new or important information (Gopen & Swan). (Ch 8)

Structure — Document-level organization — order, hierarchy, grouping — that determines whether a reader can find what they need. (Ch 4)

Structured abstract — An abstract with labeled headings (Background, Methods, Results, Conclusions). (Ch 14)

Subject line — The single guaranteed-read part of an email; it must state the topic and the action or deadline so the reader can triage without opening. (Ch 19)

Subject–verb agreement — Matching the verb to the real subject, not to the nearest intervening noun. (Ch 6)

Subordination — Making one clause dependent (with because, when, although) to encode a logical hierarchy between ideas. (Ch 6)

Supplementary materials / supporting information (SI) — Verification material kept outside a paper's main text; the main text carries the argument, the SI carries the proof. (Ch 35)

Swipe file — A running personal collection of passages that worked, each with one line on why; a self-curated style reference. (Ch 39)

Sycophancy — A model's tuned tendency to be agreeable — to lean toward "yes" and cave when pushed. Agreeableness is not accuracy. (Ch 29)

Synthesis — Combining multiple sources to make a point none of them states alone; idea-centric, with sources as evidence. The central skill of a literature review. (Ch 15)

Synthesis matrix — A table with sources down the rows and themes across the columns; read down a column for synthesis, read an empty cell for the gap. Doubles as the review's outline. (Ch 15)

Systematic review — A review answering one predefined question through an explicit, reproducible, pre-registered search protocol. (Ch 15)

T

Table — Rows and columns of exact values, for lookup or precise comparison, as opposed to a figure. (Ch 9)

The takeaway — The single thing a viewer should remember; a poster has exactly one, the way a slide has one assertion. (Ch 18)

Teach-back — Having a patient explain instructions back in their own words; the clinical version of the "someone who has never done this" test, and it replaces "Do you understand?" (Ch 36)

Technical report — The workplace form of an empirical report, organized to put the recommendation first for a decision-maker. (Ch 13)

Technically present vs. functionally present — Information being in a document versus actually reaching the reader. Closing that gap is the job. (Ch 1)

Template, not theme — Using a presentation template's surface (font, color, spacing) while overriding its content structure (prefab agendas, bulleted layouts). (Ch 30)

Testable / verifiable (requirement) — The property that there exists a method returning pass or fail. A requirement without one isn't finished. (Ch 33)

Test case — A document of how a requirement will be verified: an ID, the requirement ID, preconditions, numbered steps, an expected result, and a pass/fail criterion. Structurally, a procedure. (Ch 33)

Test report — A record of whether requirements were met — per-case pass/fail plus the actual measured value, the build, and any deviations. (Ch 33)

Thematic organization — Structuring a literature review by theme — one section per idea, sources as evidence — rather than by source. (Ch 15)

Thesis / dissertation — A sustained, governed argument (months to years, ~150–180 pages) that makes and defends an original contribution. Not a long paper. (Ch 16)

Thesis statement / claim — The one sentence the whole document serves: an assertion that could be wrong and that the work defends. Contrasted with a topic, which can't be disagreed with. (Ch 16)

Thought leadership — Establishing authority by demonstrating judgment (a useful, honest analysis) rather than asserting it. (Ch 37)

Timeline (incident) — A factual, timestamped sequence of events with no interpretation — the "Results" section of an incident report. (Ch 21)

Time-to-first-success — The metric a README (or tutorial) is optimized for: how fast a stranger gets a working result. (Ch 25)

Tolerance — The allowed deviation around a value; "approximately X" without one is a missing specification, not modesty. (Ch 33)

Tone — The attitude a piece conveys toward its subject and reader; a set of dials you turn on purpose, not an accident that happens to your prose. (Ch 7)

Tooltip — Hover text on a chart that adds interpretation, a definition, or a caveat that would clutter the chart if always shown. (Ch 27)

Top-down organization — Presenting information in the order the reader will use it, conclusion first. The default for technical documents. (Ch 4)

Topic position — The beginning of a sentence — what it's "about" — where the reader expects the familiar (Gopen & Swan). (Ch 8)

Topic sentence — The (usually first) sentence stating a paragraph's point; collectively, topic sentences form a scannable map of the document, and each is a unity check for the writer. (Ch 4, Ch 8)

Track changes — A word-processor mode that records each edit as an accept/reject suggestion (also called suggesting mode or a redline). (Ch 23)

Traceability — The ability to follow each requirement backward to its source and forward to its design element and test case. (Ch 33)

Traceability matrix — A table mapping requirement ID → source → design element → verification method → test case; blanks reveal gold-plating or unverified requirements. (Ch 33)

Transcription model (of writing) — The mistaken belief that thinking finishes in the head and writing merely records it; the "before" state of the book's central threshold concept. (Ch 1)

Transition — A word or phrase naming the logical relationship between ideas; the four types are additive, adversative, causal, and sequential. (Ch 8)

Translation without distortion — Rendering technical research into plain, actionable language without overstating what the evidence supports. The policy brief's defining discipline. (Ch 37)

Transparency (ethical obligation) — Disclosing limitations, conflicts of interest, and uncertainty; it governs a claim's foundations, distinct from accuracy (the claim itself). (Ch 38)

Trip report — A document of a business trip's takeaways and recommendations — not a day-by-day travelogue. (Ch 21)

Tutorial (learning-oriented) — A document for a beginner whose job is to guarantee a success experience: one concrete goal, a single tested path, no forks, literal steps with expected results. (Ch 26)

Type hint / type annotation — A signature declaration of a value's shape (text: str, -> datetime); documentation a tool can check, so it can't silently drift. (Ch 24)

Typography — The visual treatment of text: typeface, size, line and letter spacing. (Ch 10)

U

Unambiguous (requirement property) — Having exactly one reading; the property violated by weak words (fast, robust, user-friendly). (Ch 33)

User manual / how-to guide — End-user-facing instructions for operating a product or completing a task. (Ch 22)

User story — A short statement of a need from the user's view: "As a [user], I want [goal] so that [reason]." (Ch 34)

V

Verification (non-delegable) — You are accountable for every fact, number, and citation under your name, whatever produced it; "the AI told me" is no defense. (Ch 29)

Verification method — How a requirement is checked: Test, Inspection, Demonstration, or Analysis. If none can be assigned, the requirement isn't finished. (Ch 33)

Version control (documents) — The mechanism for keeping a document's versions straight — Google Docs history, Word track changes, or git for docs. (Ch 23)

Virtual presence — Delivering a talk on camera: audio first, look at the lens, manufacture engagement, master screen-sharing, shorten. (Ch 31)

Voice — The recognizable personality and stance that persists across registers — the human behind the prose. (Ch 7)

W

Watermelon report — Green-outside, red-inside reporting, where everything stays green until it suddenly fails; it destroys a status report's early-warning value. (Ch 21)

Weasel word — A word that implies a claim while committing to nothing (studies show, up to, can help). (Ch 7)

White paper — A longer-form document examining a problem in depth, usually as thought leadership; it earns authority only by being genuinely useful. Its failure mode is the brochure-with-footnotes. (Ch 37)

White space (negative space) — The empty area in a layout (margins, gaps); a structural tool that groups, separates, and rests the eye, not wasted room. (Ch 10)

The why, not the what (canonical rule) — Comment the reason behind code — intent, constraint, decision — because the code already states what it does. (Ch 24)

Whistleblowing — The extreme escalation when a document is dangerously wrong and internal channels fail; flagged as beyond a writing book's scope. (Ch 38)

WCAG — The Web Content Accessibility Guidelines (W3C); the source of the contrast-ratio and color-independence rules. (Ch 10)

Work instruction / assembly procedure — Procedural writing on the factory floor: exact value plus tolerance, pattern, sequence, and in-line verification, so the build is repeatable across people and units. (Ch 33)

Writer's block (as diagnosed here) — Not a lack of ideas but an editing impulse arriving during drafting — the judging voice strangling the generating one. (Ch 5)

Writing as thinking — Writing is not recording finished thought; it is the act in which thinking gets finished and tested. The book's foundational idea. (Ch 1)

The writing process (five stages) — Plan → Draft → Revise → Edit → Proofread: five distinct jobs done in separate passes rather than all at once. (Ch 5)

Written elevator pitch — A recommendation, its stakes, and the ask in two or three sentences (hook → stakes → next step), written to create motion. (Ch 37)

See also the Index for where each term is used across the book, and Chapter 7 (Word Choice, Tone, and Voice) and Chapter 11 (Citing Sources) for the conventions behind much of this vocabulary.