What is technical writing, and what makes documentation good?
Writing whose purpose is to help someone do something or understand something, judged entirely by whether they succeed — which makes it the one form of writing with an objective quality test.
The types, which have different jobs and are frequently conflated into an unusable mess:
Tutorials — learning-oriented. A beginner follows steps to a working result. The goal is confidence, not completeness, and a tutorial that explains every option fails.
How-to guides — task-oriented. A competent user achieves a specific goal. Assumes context, omits teaching.
Reference — information-oriented. Complete, accurate, consistently structured, consulted rather than read.
Explanation — understanding-oriented. Background, reasoning, alternatives considered, why it works this way.
This four-way split is the single most useful idea in the field, because most bad documentation is a tutorial interrupted by reference material and an argument about design philosophy.
What makes documentation actually good:
It is written for a stated reader with stated prior knowledge.
It is task-oriented where tasks are what the reader has. People arrive wanting to do something, not to learn your architecture.
It is tested by someone following it, which catches the steps the author knew and omitted. The curse of knowledge is the fundamental problem, and only an outsider reveals it.
Examples are complete and runnable, since a fragment requiring assembly is a puzzle.
It states prerequisites and expected outcomes up front.
It says what to do when it goes wrong, which is where readers actually are when reading.
It is findable, since undiscoverable documentation does not exist.
It is maintained, and wrong documentation is worse than none because it is trusted.
The craft specifics: the imperative mood for instructions; one action per step; consistent terminology, since synonyms that aid prose harm reference; screenshots used sparingly, as they date fastest; and version labelling.
Docs-as-code — keeping documentation in version control alongside the software, reviewed in the same pull request — is the practice most associated with documentation staying accurate.