Books › Technical Writer roadmap
Best books for Technical Writers
Writing craft first, documentation craft second. The opening books cover clear nonfiction writing, style and a general handbook. The build set covers documentation for developers, topic-based writing, readable web content, information quality and writing as design. The lead set covers content strategy, information architecture, structuring arguments and difficult conversations with subject experts.
12 books in 3 stages, about 3,500 pages (at least 88 hours of reading). The notes are ours, with no ratings or sales claims.
How to choose your books
A short method, so you read the right book for where you are instead of the longest list.
Find your stage
Getting started · 3 books
Clear writing: nonfiction craft, style and a general technical-writing handbook.
Jump to this stage ↓Doing the job · 5 books
Documentation craft: developer docs, topic-based writing, scannable web content, information quality and writing as design.
Jump to this stage ↓Senior and leading · 4 books
Content systems and influence: strategy, information architecture, structured argument and handling difficult conversations.
Jump to this stage ↓
If you are unsure, start one stage lower than you think. Books in a later stage assume the working knowledge the earlier ones give you.
Begin with one book
Our starting pick
On Writing Well: The Classic Guide to Writing Nonfiction
by William Zinsser · 1976
Technical writing is writing first. This book teaches the clarity and economy every document you write will depend on.
See the book ↓Then pick by your situation
Choose the next book by the problem in front of you, not by its place in the list.
If you document software for developers
read Docs for Developers (doing the job)
If readers arrive at any page from search and need it to stand alone
read Every Page Is Page One (doing the job)
If you are organising a large body of documentation
read Information Architecture (senior and leading)
Set a time budget
| Stage | Books | Pages | Reading | At 3 hrs a week |
|---|---|---|---|---|
| Getting started | 3 | 1,090 | 27 hrs | 9 wks |
| Doing the job | 5 | ≥ 1,270 | ≥ 32 hrs | ≥ 11 wks |
| Senior and leading | 4 | 1,140 | 29 hrs | 10 wks |
| All 3 stages | 12 | ≥ 3,500 | ≥ 88 hrs | ≥ 29 wks |
Treat this as a ceiling, not a target. Read one book at a time, apply it, then move on; read reference-style books in sections. Totals are approximate.
Judge any book before you buy it
Age
This list runs from 1918 (The Elements of Style) to 2021 (Docs for Developers). Older books earn their place by teaching principles that do not change. For tools and platforms, buy the latest edition.
Level
Check the stage before the title. A book from a later stage will make sense only once you have faced the problems it solves.
Format
The longest book here, The Handbook of Technical Writing, 12th Edition, runs about 640 pages. Read very long books as references: pick the chapter that matches the problem you have.
Fit
Ask what you will do differently the week after you finish. If you cannot answer, the book is for a different moment. Come back to it when the situation arrives.
Getting started
Clear writing: nonfiction craft, style and a general technical-writing handbook.
Start hereOn Writing Well: The Classic Guide to Writing Nonfiction
by William Zinsser · 1976
~340 pages~9 hrs to read
Clear, humane advice on simplicity, clutter and structure in nonfiction. A good base for writing procedures and explanations people can follow.
View book →
The Elements of Style
by William Strunk Jr., E. B. White · 1918
~110 pages~3 hrs to read
A compact reference on usage, composition and common errors. Keep it close in your first months while you build editing habits.
View book →
The Handbook of Technical Writing, 12th Edition
by Gerald J. Alred, Charles T. Brusaw, Walter E. Oliu · 1976
~640 pages~16 hrs to read
An A-to-Z reference covering document types, graphics, grammar and formatting for technical communication. Use it to look up conventions as questions come up.
View book →
Doing the job
Documentation craft: developer docs, topic-based writing, scannable web content, information quality and writing as design.
Docs for Developers: An Engineer's Field Guide to Technical Writing
by Jared Bhatti, Zachary Sarah Corleissen, Jen Lambourne, David Nunez, Heidi Waterhouse · 2021
Walks through planning, writing, publishing and measuring documentation for software projects. The most direct match for what developer-facing docs jobs involve.
View book →Every Page Is Page One: Topic-based Writing for Technical Communication and the Web
by Mark Baker · 2013
~290 pages~7 hrs to read
Argues that readers arrive from search at any page, and shows how to write self-contained topics. Changes how you structure docs for the web.
View book →
Letting Go of the Words: Writing Web Content that Works
by Janice (Ginny) Redish · 2007
~330 pages~8 hrs to read
Covers writing for people who scan, search and want to finish a task. Useful for turning drafts into pages readers can use quickly.
View book →
Developing Quality Technical Information: A Handbook for Writers and Editors
by Gretchen Hargis, Michelle Carey, Ann Kilty Hernandez, Polly Hughes, Deirdre Longo, Shannon Rouiller, Elizabeth Wilde · 1997
~450 pages~11 hrs to read
Defines what makes technical information easy to use, accurate and complete, with checklists for editing. Handy for reviewing your own work and others'.
View book →
Writing Is Designing: Words and the User Experience
by Michael J. Metts, Andy Welfle · 2020
~200 pages~5 hrs to read
Treats words as part of interface design, with guidance on voice, tone and working with designers. Helps when your writing sits inside the product, not beside it.
View book →
Senior and leading
Content systems and influence: strategy, information architecture, structured argument and handling difficult conversations.
Content Strategy for the Web
by Kristina Halvorson, Melissa Rach · 2009
~200 pages~5 hrs to read
Explains how to plan, create and govern content across an organization. Read it when you start deciding what documentation to build and how to maintain it.
View book →
Information Architecture: For the Web and Beyond
by Louis Rosenfeld, Peter Morville, Jorge Arango · 1998
~460 pages~12 hrs to read
Covers organizing, labeling and navigating large bodies of content. Useful for structuring documentation sets that scale past a few dozen pages.
View book →
The Pyramid Principle: Logic in Writing and Thinking
by Barbara Minto · 1987
~180 pages~5 hrs to read
A method for structuring arguments from the main point downward. Helps with design docs, proposals and documentation strategy for senior audiences.
View book →
Crucial Conversations: Tools for Talking When Stakes Are High
by Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler · 2002
~300 pages~8 hrs to read
Techniques for handling high-stakes disagreements calmly. Useful for negotiating with engineers and product managers over review time and doc ownership.
View book →
Book links go to Amazon and are affiliate links. As an Amazon Associate I earn from qualifying purchases.
Frequently asked questions
Which book should a Technical Writer read first?
On Writing Well: The Classic Guide to Writing Nonfiction by William Zinsser. Technical writing is writing first. This book teaches the clarity and economy every document you write will depend on.
Do I need to read all 12 books?
No. The list is a menu, not a syllabus. Find your stage (getting started: 3, doing the job: 5, senior and leading: 4), begin with one book (we suggest On Writing Well: The Classic Guide to Writing Nonfiction), then pick the next book by the problem you are facing at work. Come back to the others when the situation they cover arrives.
How long does it take to read these books?
The 11 books with a known page count add up to about 3,500 pages, roughly 88 hours at 1.5 minutes a page. At three hours a week that is about 29 weeks; at six hours a week, about 15. The list is meant to be read over time, one book at a time, not in one run.
Are these books up to date?
They range from 1918 (The Elements of Style) to 2021 (Docs for Developers). Older titles are included because they teach principles that have not changed; for tools and platforms, we favour recent editions. Check the edition before you buy.
Related reading
Some links are affiliate links: we earn a small commission if you buy, at no cost to you. It does not change what we list.