A shelf of books is no longer a learning plan
Ten years ago, a newcomer could work through a few respected technical-writing books, learn a publishing tool, and have a reasonable curriculum for several months. In 2026 that list ages too quickly. Interfaces change, generative AI has entered editorial workflows, Git and automated checks are routine in many software teams, and public style guides can change faster than a printed edition.
Books are still useful because they can develop a long argument about audience, quality, structure, or team practice. A living online guide answers a different question: how should a command, heading, code sample, UI label, term, or procedure be written now? A good curriculum uses both.
As of August 2026, Microsoft and Google continue to update their public writing guidance, GitHub publishes its Docs content models and design principles, IBM maintains public content standards, and Diátaxis remains an active practical system for separating tutorials, how-to guides, reference, and explanation. Comparing these traditions on the same problem is more useful than declaring one book the universal authority.
Five living guides worth keeping open
| Source | Best at | Concrete model | Open it when |
|---|---|---|---|
| Microsoft Writing Style Guide | Voice, procedures, UI, terminology | Simple sentences, active voice, direct actions, intent first | Prose feels formal, indirect, or bureaucratic |
| Google developer documentation style guide | Developer docs, global audience, code, headings | Put conditions before instructions, address the reader directly, format code entities as code | Writing API, CLI, cloud, or localization-heavy docs |
| GitHub Docs style and content model | User goals, article structure, scannability | Start from user need, publish just enough docs, choose a content type | An article keeps growing without a clear purpose |
| IBM Content Standards | Systematic quality review | Treat task orientation, accuracy, completeness, clarity, organization, and retrievability as separate qualities | Review needs more than “I like this wording” |
| Diátaxis | Information architecture and content types | Keep tutorial, how-to, reference, and explanation distinct | Reference turns into a course or a tutorial turns into an encyclopedia |
The sources work at different levels. Microsoft and Google often help at the sentence and procedure level. GitHub adds content design. IBM gives reviewers a vocabulary for judging an information product. Diátaxis asks whether the page is the right type of page in the first place.
Compare the same problem across traditions
Start with a deliberately poor instruction:
In order to successfully complete the operation, users should ensure that the repository has previously been initialized, after which the Create button should be clicked.
A Microsoft-style edit moves toward a direct instruction:
Initialize the repository, then select
Create.
Google guidance draws attention to conditions before actions. If initialization is a prerequisite:
Before you select
Create, initialize the repository.
GitHub content design asks what the reader is trying to accomplish:
To create the project, initialize the repository, then select
Create.
IBM does not stop at sentence polish. A reviewer asks whether initialization is truly required, whether “repository” is understood by this audience, and whether the result of the action is documented. A beautifully edited false prerequisite is still bad documentation.
Diátaxis might remove the procedure from this page entirely. Reference describes the system; goal-directed steps belong in a how-to guide. A structural decision can be more valuable than another pass over the wording.
The same test works for a vague heading such as “Working with repositories.” A task page benefits from a specific title such as “Create a repository” or “Configure repository access.”
Study one problem at a time, with an actual assignment
“Study task design” is not a learning exercise. Attach the topic to a document you can change and an outcome you can inspect.
| Real problem | Read/compare | 60–90 minute exercise | Artifact |
|---|---|---|---|
| Procedure hides prerequisites | Microsoft procedures + Google instruction guidance | Rewrite one real procedure: move conditions before steps and add an observable result | Before/after plus a local rule |
| API reference contains pages of explanation | Diátaxis Reference + Google code samples | Separate endpoint facts from the usage scenario | Cleaner reference and a how-to candidate |
| Terms vary across pages | Google word list + Microsoft terminology guidance | Audit 20 repeated terms and choose preferred forms | Mini glossary and lint candidates |
| Reviews repeat the same 50 comments | IBM quality model + GitHub content principles | Split comments into machine-checkable and judgment-based | Machine/human review map |
| Localization exposes ambiguous prose | Google global-audience guidance + IBM globalization principles | Rewrite two pages without idioms, vague pronouns, or cultural shortcuts | Local before/after examples |
| AI draft sounds plausible but may be wrong | TechWriters AI fact-checking article + product truth sources | Mark each verifiable claim with code, UI, schema, test, or SME evidence | A fact-check map |
After one evening you have not “completed the Google guide.” You do have one tested improvement and one rule you can apply again.
Turn reading into a skill
Useful learning starts with a defect in your own documentation, not a bibliography.
Suppose reviewers keep asking what happens after a step. Compare procedure guidance, inspect strong public examples, rewrite one procedure so important steps have observable outcomes, and see whether the next review changes. If the solution repeats, add it to local style. If it can be formalized, automate it.
A learning log should therefore record changed artifacts, not only book titles: the original fragment, the rule you tested, the review result, and the decision your team kept.
Books that still help, and what has aged
An old publication can remain valuable if you separate its reasoning model from tooling and workflow details that have moved on.
| Book | Why read it now | Treat as historical context |
|---|---|---|
Docs for Developers (2021) |
End-to-end view from audience and planning through code samples, publishing, feedback, metrics, and maintenance | It predates the current LLM wave, so AI-assisted authoring and fact-checking need a modern layer |
Developing Quality Technical Information, 3rd ed. (2014) |
Strong quality model: task orientation, accuracy, completeness, clarity, organization, retrievability | Delivery stack and some organizational assumptions predate current docs-as-code and LLM workflows |
Every Page Is Page One (2013) |
Excellent lens for pages entered from search: context, self-contained topics, links, metadata | Search behavior now also includes AI answers and modern doc portals |
The Product is Docs |
Useful product-team perspective: audience work and collaboration with QA, support, product, and engineering | Specific team practices should be tested against your organization and current automation |
A book is most useful when it gives you something to test or argue with in your own project. Blindly preserving a fifteen-year-old recipe is less useful than comparing its model with today’s process.
Build your own style guide from tested decisions
Microsoft, Google, or GitHub should not become your team’s constitution. Project-specific guidance exists because product vocabulary, audience, risk, and technology differ.
A local style guide should grow from recurring questions. If three reviews debate the same term, decide the term. If API examples use five structures, define one pattern. If every review argues about UI labels, make one local decision. A rule earns its place by preventing the next unnecessary debate.
Keep four fields for a local rule: the problem, the decision, a good example, and an exception.
| Field | Example |
|---|---|
| Problem | log in, login, and sign in all describe one user action |
| Decision | Use sign in for the user action; retain login only for literal technical names |
| Good example | “Sign in to the admin console.” |
| Exception | An API field named login remains login |
After a few months, this local file becomes more valuable than any external guide because it contains decisions about your system. External guides remain comparison tools, not laws.
What to do this week
Do not start by reading five large guides cover to cover. Pick one project page that already received a complaint from a reader, SME, or editor. State the defect in one sentence and find two sources that approach that defect differently.
The next day, create a before/after version and show it to someone who actually uses the documentation. If the change survives review, record the decision locally. By the end of the week you will have one improved page, one tested editorial hypothesis, and possibly one new team rule — a better outcome than a list of chapters completed.
Repeat the cycle on another problem next month. The pace looks less impressive than a twenty-book marathon, but it builds an actual documentation practice.
