A reading and practice group, not a course. Each post covers one topic and ends with an exercise. Work through them in any order.

The articles aren't exhaustive. They're designed to give you a starting point, with references for further exploration.
Three posts per week — Monday, Wednesday, and Friday.
The unique challenge of writing documentation for products whose behavior changes based on input, context, and probability.
Practical prompt frameworks for documentation tasks.
Moving from writing what you're asked for to shaping what gets asked.
AI can produce the documentation. Someone still has to know it's right.
The same procedure in three documents is three maintenance jobs. Single-sourcing makes it one.
Let the machine hold the style guide in memory, so your reviewers can spend their attention on what it can't check.
Don't write a house style from scratch. Adopt a base, document only where you diverge, and put it where writers already work.
How to evaluate what fits your team's needs.
What the most important toolchain shift in technical writing means for you.
A diagram in a design tool goes stale in two years. A diagram in text gets reviewed in the pull request that changes it.
When an image earns its place, when it's just filling space, and why every screenshot you add is a bill that comes due.
The guidelines run to hundreds of criteria. As a writer, you’ll touch the same three every day.
The words users read inside the product, while the docs stay closed.
The most verifiable thing you'll write, and the most likely to rot — here's how to keep samples current.
A commit says a change happened. A release note says what it means — and the only way to bridge them is to ask.
The tool generates the reference. The judgment, the examples, and the spec itself are still yours.
You don't need to write production code. You need the vocabulary, an API client, and one successful request.
The infrastructure that makes content findable and usable by both humans and AI systems.
Structure documentation so users can find what they need.
Diátaxis is the one to start with, but DITA, minimalism, and others fill the gaps it leaves open.
Designing a review cycle that ends, and getting sign-off from people who'd rather not give it.
Without losing your mind..
What the rule actually protects against, and when passive is correct.
Developmental, copy, and mechanical — and why conflating them wastes reviewer time.
Precision and simplicity are the same goal, not a tradeoff.
How people actually scan a page, and what that means for structure.
Includes the companion persona workbook.
The job as it exists now, not as the job title suggests.
Surviving the two-week sprint (September 14) · Task management and ticket systems (September 16) · Proving your worth: documentation metrics (September 18)
What the job is · Writing craft · Editing
The psychology of the SME · Review and approval workflows · Documentation frameworks · Information architecture · Metadata and taxonomy
API docs 101: demystifying REST · Beyond REST: OpenAPI and Swagger · From Git commits to release notes · Code samples and code comments · Intro to UX writing · Writing for everyone: accessibility · Visuals that work (and don't) · Diagrams as code: Mermaid and Draw.io
The shift to docs-as-code · Choosing your authoring environment · Enforcing style guides without being a cop · Automated linting and consistency checking
Write once, publish everywhere · Writing for translation and localization · The technical writer as strategist
The technical writer as context owner · Prompt engineering for tech writers · Documenting AI and non-deterministic software
Surviving the two-week sprint · Task management and ticket systems · Proving your worth: documentation metrics · The art of deleting: content audits
Building the NDA-proof portfolio · Contracting vs. full-time