Mostly harmless, conspicuously useful
The Hitchhiker's Guide to Becoming a Developer Advocate
A developer advocate bridges a product and its developer community through content, code, and feedback loops, which is a perfectly reasonable arrangement until you recall that the demo worked on the laptop and not on the stage, that the tutorial assumes the reader already knows the thing it explains, and that the community's feedback the product team is grateful for and surprised by is the same feedback the advocate channelled and the product team forgot to read. You learn to translate "developers will love this" into tutorials, talks, samples, and feedback reports that survive contact with an actual developer who has never heard of your product and is in a hurry. The grand objective is a developer who succeeds without you and a product that improves without being asked; the daily evidence is usually a sample that compiles, a talk whose recording captures the slide that worked and the demo that did not, and a feedback loop that closes before the community closes it for you. This guide travels from reading the docs to governing developer relations strategy, with practical stops at content, community, education, and the recurring discovery that the audience is always more diverse than the tutorial assumes.
Level 1 · Novice
Run the sample before you trust it, then run it on a different machine
You read docs, samples, and tutorials without publishing any, learning how a sample that compiles on your machine can fail on a reader's and a tutorial that makes sense to you can assume the thing it explains.
You begin with read-only artifacts: documentation, sample repositories, tutorial drafts, talk recordings, and a feedback channel expressing recent opinions. Technical content is the tutorials, talks, videos, and blog posts developers trust — or do not; sample code is the demos, SDK-quality examples, and reference integrations that prove the product works outside the demo. You read these with experienced advocates, contributors, and the occasional confused reader so you can distinguish a tutorial that teaches from a tutorial that assumes the reader already knows the thing it explains.
Suppose you read a getting-started tutorial that begins "assuming you have already configured your credentials and a cluster." You follow it on a fresh machine and discover that "already configured" is doing a great deal of work: the credentials require a sign-up, a confirmation email, a role assignment, and a region the tutorial does not mention. You record the gap, the missing prerequisite, and the reader who would be lost at step one. One brisk review is an anecdote with good posture, not a developer-experience audit; but it prevents the team from publishing a tutorial whose first sentence is a polite eviction.
Words from the spaceship manual, translated
- Technical content
- Tutorials, talks, videos, and blog posts developers trust. It is the difference between "developers will love this" and "developers loved this," and the gap is measured by whether the reader finishes the tutorial.
- Sample code
- Demos, SDK-quality examples, and reference integrations that prove the product works outside the demo. A sample that compiles only on the author's machine is a souvenir, not a reference.
- Prerequisite
- A condition the tutorial assumes the reader has already met — a credential, a tool, a region, a cluster. It is the polite eviction notice at the top of the tutorial that decides who finishes it.
- Feedback channel
- The route by which the community reports confusion, bugs, and requests — issues, forums, chat, social. It is where the tutorial's assumptions meet the reader's reality and produce a queue the advocate triages.