New: Roadmaps ordered paths through our cheat sheets and flashcards, so you always know what to study next.
Explore themSee what's new on GitHubFrom a clear first paragraph to a documentation system engineers actually trust.
A 11-step learning path. Follow it in order, or jump to what you need.
This path is for anyone turning writing into a docs craft: aspiring technical writers, developers who keep getting handed the docs, and support or QA folks moving into a documentation role. It runs about 4 to 6 weeks at a few hours a week. This path stays on docs craft, not developer marketing: it does not cover blog content, conference talks, or community building, which belong to the Developer Relations path instead. By the end you can write and structure a technical document from scratch, publish it through a real docs-as-code pipeline with diagrams and version control, and produce an OpenAPI-driven API reference and an architecture decision record other engineers actually read.
Expected: comfortable writing clear, plain English. Helpful but not required: prior exposure to Git or reading an API's documentation.
Open this first: every later step assumes you can already turn a tangle of facts into a document someone follows without pinging you, and that plain-language, structure-first habit is what step 3 goes on to formalize with the field's own vocabulary of tutorial, how-to, and reference.
Every doc you structured in step 1 gets written in Markdown day to day, so pick up the syntax that turns your headings and tables into something both Git and a docs site can render.
Go deeper on the doc-type thinking step 1 only sketched: knowing whether you're writing a tutorial, a how-to, or a reference, and mapping your reader's journey through it, keeps one page from trying to be all three at once.
You can turn a messy process into a page that reads plain and holds together, tutorial, how-to, or reference, whichever the moment calls for. Next up: making that page visual and versioned.
Finish this section to unlock.
+100 XP
Some of the tables you built with Markdown in step 2 are clearer as a picture: pick up Mermaid and PlantUML so a flow or a system boundary lives in plain text right next to the words describing it.
Turn the Markdown pages and diagrams you can now build in steps 2 and 4 into a searchable site with navigation and version history, the way real docs teams publish instead of emailing a file around.
Docs stop living in a shared drive once you connect them to Git: the site you just built in step 5 needs pull requests and history to stay trustworthy, and that review-and-merge habit takes a minute to feel natural before it becomes routine.
Your pages now carry diagrams, live on a real docs site, and move through Git like any other code change. Next up: writing straight from an API instead of just about one, and a few due flashcards a day keeps the plain-language habits from chapter 1 fresh while you build on them.
Finish this section to unlock.
+100 XP
Expect this step to upend how you write about an API: instead of describing endpoints in prose the way step 1 taught, you write from the OpenAPI structure itself, and that shift from paragraphs to schema is the one every API-docs specialist has to make.
Take this if you're heading toward deep API-documentation specialization: knowing why an API is shaped the way it is makes the reference you write from step 7's spec far more accurate.
Reach for this if you want every code sample you publish to be one you've actually run: Postman lets you fire the requests from step 7's OpenAPI spec and catch a stale example before a reader does.
Add this to your kit if you want an automated second pass on the style rules from step 1: a grammar and clarity checker catches what a deadline makes you miss.
Pull the diagrams from step 4, the docs-as-code habits from step 6, and the structured writing from step 7 into the format senior technical writers own: architecture decision records and system diagrams stakeholders actually read.
You can write from an OpenAPI spec instead of guessing at it, verify your own examples, and turn a system's moving parts into diagrams and decision records other engineers actually read. That's the Technical Writer badge: docs craft end to end, from a clean sentence to an architecture record.
Finish this section to unlock.
+100 XP
Finish every required step, at least 70% of them genuinely done (not skipped), to earn this badge and 500 XP.