Courses, portfolios, deliberate practice and professional development.
A useful reading list is no longer a shelf of classics. Compare actively maintained Microsoft, Google, GitHub and IBM guidance, use Diátaxis to test content structure, and turn each reading session into a concrete documentation exercise.
Reading about documentation helps, but skill grows faster when you repeatedly perform small research, restructuring, editing and verification exercises with clear feedback. “Improve technical writing” is too broad to train.
Short repeated editing exercises train diagnosis: finding ambiguity, missing conditions, weak structure and unnecessary words in real documentation. Practice one defect at a time: prerequisites, vague verbs, terminology, long sentences or missing outcomes.
A new technical writer learns faster by mapping the product, users, publishing system and decision makers before trying to rewrite everything. First month: map product areas, audiences, source repositories, build, reviewers and release flow.
A tiny working API gives a technical writer enough surface area to practice reference, concepts, examples, errors and onboarding without a large project. Keep the API intentionally small; the goal is documentation practice, not backend engineering.
Hiring teams need evidence of how you investigate, structure and verify documentation. A strong portfolio explains the problem, constraints, process and result instead of displaying isolated polished screenshots. A polished article shows that you can produce polished text.