Further Reading — Chapter 26: Technical Tutorials and How-To Content

Annotated, and limited to sources we can stand behind (Tier 1 verified; Tier 2 attributed). Start with the first two—they are the spine of this chapter.

Tier 1 — Verified, foundational

Daniele Procida, Diátaxis — the documentation framework (diataxis.fr). The source of this chapter's central idea. Procida's framework divides technical documentation into four modes—tutorials, how-to guides, reference, and explanation—along the two axes this chapter uses (study vs. work, practical vs. theoretical), and argues that conflating them is the root cause of most documentation pain. The site is itself a model of the thing it teaches: clear, well-structured, and organized by exactly the four modes it describes. Read "Tutorials" and "How-to guides" first; they sharpen the distinction this whole chapter rests on. If you read one external thing about documentation in your career, read this.

Write the Docs — community and guides (writethedocs.org). A global community of documentation practitioners with an excellent, free set of guides covering documentation structure, the docs-as-code workflow, style, and how teams actually maintain docs at scale. Their material reinforces the Diátaxis distinction and extends it into the practical realities of maintaining tutorials and how-tos (the screenshot-rot and assumed-step problems are lived experience here, not theory). Their conference talks (many freely available) are a fast way to absorb how working technical writers think.

Strunk & White, The Elements of Style. Still the baseline for the sentence-level craft that a good tutorial needs as much as any other document. A tutorial's prose must be invisible so the reader's attention stays on the task—and that invisibility is built from the concision and clarity this book has championed since Chapter 3. Short.

Tier 2 — Attributed ideas worth chasing

Research on the curse of knowledge (broadly attributed; the classic demonstration is the "tappers and listeners" study). The cognitive bias underneath this chapter's assumed step: once you know something, you cannot easily model not knowing it, so you systematically overestimate how clear your instructions are. Worth understanding as a mechanism, because it explains why the fix is never "try harder to imagine the beginner" (you can't) but always "get the assumption out of your head and into a clean environment or a real beginner's hands." (You met this in Chapter 2; here it has teeth.)

The "minimalist instruction" tradition in technical communication (associated with John Carroll's work on the minimal manual). A body of research arguing that learners do better with lean, action-oriented, get-them-doing-quickly documentation than with exhaustive manuals—the empirical backbone of "teach the happy path, defer the edge cases." If you want evidence that a shorter tutorial often teaches better, this is the tradition to read about.

Vendor tutorial style guides (e.g., the documentation style guidance published by major open-source projects and cloud platforms). Many large projects publish their own writing guidelines for tutorials and how-tos, and the good ones encode the Diátaxis distinction explicitly. Reading one for a tool you use is a fast way to see these principles enforced in the wild—and to see how a real team separates "getting started" from "how to."

A note on what's not here: this list excludes the dozens of "10 tips for better tutorials" blog posts that circulate online. They tend to repeat surface advice without the framework that makes it coherent. Procida's Diátaxis gives you the why behind every tip, which is worth more than any list of tips—because once you know which mode you're writing, most of the "tips" become obvious consequences.