Books › Developer Advocate roadmap
Best books for Developer Advocates
This list follows how a developer advocate grows. It starts with sharing work in public, ideas that stick, talk design and technical writing. It builds craft: story, adoption, software craft, API design, open-source community and usability. It ends with leading others through feedback and growth. Read in order if you are new, or jump to the stage where your public work feels weakest.
The first months in the role
A developer advocate spends the early months learning what developers actually struggle with, which is rarely what the product page promises. Use the product yourself on a real task, note every point of friction, and bring that list to the product team before you publish anything. The friction list is often the most useful thing you will write all year.
Write early and often. A tutorial you have tested on a clean machine is worth more than a polished talk that has never been run. Keep examples small and working, and link them from everything you publish.
Questions you may be asked
- How would you explain a complex API to a developer who has never used it?
- Tell me about documentation you improved. What did you change?
- How would you tell whether a tutorial helped someone, without relying on vanity numbers?
Common mistakes, and what to read
Writing for the product team instead of the developer. Start from the task the reader is trying to finish.
See Docs for Developers on this list.
Publishing examples that have not been run from scratch. Test every step on a fresh environment before release.
See The Pragmatic Programmer on this list.
12 books in 3 stages, about 2,960 pages (at least 74 hours of reading). The notes are ours, with no ratings or sales claims.
See the full Developer Advocate roadmap →Best courses for Developer Advocates →
How to choose your books
A short method, so you read the right book for where you are instead of the longest list.
Find your stage
Getting started · 4 books
Sharing work in public, ideas that stick, talk design and technical writing: the habits behind a public body of work.
Jump to this stage ↓Doing the job · 6 books
Craft and community: story, adoption, software craft, API design, running an open-source project and usability.
Jump to this stage ↓Senior and leading · 2 books
Leading advocates and programmes: feedback and the move from engineer to manager.
Jump to this stage ↓
If you are unsure, start one stage lower than you think. Books in a later stage assume the working knowledge the earlier ones give you.
Begin with one book
Our starting pick
Show Your Work!: 10 Ways to Share Your Creativity and Get Discovered
by Austin Kleon · 2014
A short, practical book on working in public. Developer relations hiring depends on a visible record, and this gives you the habits to build one without waiting for permission.
See the book ↓Then pick by your situation
Choose the next book by the problem in front of you, not by its place in the list.
If you are writing a tutorial or a guide that people must complete
read Docs for Developers (getting started)
If you want to build or join an open-source community
read Producing Open Source Software (doing the job)
If you are building a talk and want it to land
read Presentation Zen (getting started)
Set a time budget
| Stage | Books | Pages | Reading | At 3 hrs a week |
|---|---|---|---|---|
| Getting started | 4 | ≥ 820 | ≥ 21 hrs | ≥ 7 wks |
| Doing the job | 6 | 1,630 | 41 hrs | 14 wks |
| Senior and leading | 2 | 510 | 13 hrs | 4 wks |
| All 3 stages | 12 | ≥ 2,960 | ≥ 74 hrs | ≥ 25 wks |
Treat this as a ceiling, not a target. Read one book at a time, apply it, then move on; read reference-style books in sections. Totals are approximate.
Judge any book before you buy it
Age
This list runs from 1991 (Crossing the Chasm) to 2021 (Docs for Developers). Older books earn their place by teaching principles that do not change. For tools and platforms, buy the latest edition.
Level
Check the stage before the title. A book from a later stage will make sense only once you have faced the problems it solves.
Format
Some books suit reading start to finish; others work as references. Read the reference-style ones in sections, when a problem calls for them.
Fit
Ask what you will do differently the week after you finish. If you cannot answer, the book is for a different moment. Come back to it when the situation arrives.
Getting started
Sharing work in public, ideas that stick, talk design and technical writing: the habits behind a public body of work.
Start hereShow Your Work!: 10 Ways to Share Your Creativity and Get Discovered
by Austin Kleon · 2014
~220 pages~6 hrs to read
Short chapters on sharing your work in public: show process, teach what you know and let people find you. It is the habit that DevRel hiring depends on, and it is easy to start this week.
View book →
Made to Stick
by Chip Heath, Dan Heath · 2007
~300 pages~8 hrs to read
A framework for ideas that people understand and remember. Useful for tutorials, talks and launch posts, where the aim is for a developer to retain one idea and act on it.
View book →
Presentation Zen
by Garr Reynolds · 2007
~300 pages~8 hrs to read
How to design slides that support a talk instead of replacing it. Helpful for conference and meetup talks, where an overloaded slide hurts the speaker.
View book →
Docs for Developers: An Engineer's Field Guide to Technical Writing
by Jared Bhatti, Heidi Waterhouse · 2021
A field guide to technical writing for engineers: planning, drafting, structure and maintenance. It is the practical manual for the tutorials, guides and samples you will publish every week.
View book →
Doing the job
Craft and community: story, adoption, software craft, API design, running an open-source project and usability.

Wired for Story: The Writer's Guide to Using Brain Science to Hook Readers from the Very First Sentence
by Lisa Cron · 2012
~260 pages~7 hrs to read
How stories hold attention, drawn from brain science. Use it to shape a talk or a case study so that developers stay with the point and the example.
View book →
Crossing the Chasm
by Geoffrey A. Moore · 1991
~270 pages~7 hrs to read
Explains how technology products cross from early adopters to the wider market. It helps you see where your developer audience sits and what they need in order to adopt.
View book →
The Pragmatic Programmer: Your Journey to Mastery
by David Thomas, Andrew Hunt · 1999
~350 pages~9 hrs to read
A craft book for software developers. It keeps you credible when you write code in public, with habits like small steps, clear tests and honest estimates.
View book →
Designing Web APIs
by Brenda Jin, Saurabh Sahni, Amir Shevat · 2018
~230 pages~6 hrs to read
How web APIs are designed and used. Since much of the job is helping developers use an API, it gives you a design point of view to give back to the product team.
View book →
Producing Open Source Software: How to Run a Successful Free Software Project
by Karl Fogel · 2005
~300 pages~8 hrs to read
The classic guide to running an open-source project: starting, communicating, choosing licences and handling disputes. It is the best single book for the community side of the job.
View book →
Don't Make Me Think, Revisited
by Steve Krug · 2000
~220 pages~6 hrs to read
Why people struggle with web pages and how to design for how they actually read. It is useful for judging your own docs and sample sites with a user's eyes.
View book →
Senior and leading
Leading advocates and programmes: feedback and the move from engineer to manager.

Radical Candor
by Kim Scott · 2017
~270 pages~7 hrs to read
A framework for direct, caring feedback. Advocates give honest feedback to product teams and to community members, and managers use it to coach their teams.
View book →
The Manager's Path
by Camille Fournier · 2017
~240 pages~6 hrs to read
A level-by-level guide from technical lead to executive. Read it when you are asked to lead advocates or run a programme and need to know how the job changes.
View book →
Book links go to Amazon and are affiliate links. As an Amazon Associate I earn from qualifying purchases.
Frequently asked questions
Which book should a Developer Advocate read first?
Show Your Work!: 10 Ways to Share Your Creativity and Get Discovered by Austin Kleon. A short, practical book on working in public. Developer relations hiring depends on a visible record, and this gives you the habits to build one without waiting for permission.
Do I need to read all 12 books?
No. The list is a menu, not a syllabus. Find your stage (getting started: 4, doing the job: 6, senior and leading: 2), begin with one book (we suggest Show Your Work!: 10 Ways to Share Your Creativity and Get Discovered), then pick the next book by the problem you are facing at work. Come back to the others when the situation they cover arrives.
How long does it take to read these books?
The 11 books with a known page count add up to about 2,960 pages, roughly 74 hours at 1.5 minutes a page. At three hours a week that is about 25 weeks; at six hours a week, about 12. The list is meant to be read over time, one book at a time, not in one run.
Are these books up to date?
They range from 1991 (Crossing the Chasm) to 2021 (Docs for Developers). Older titles are included because they teach principles that have not changed; for tools and platforms, we favour recent editions. Check the edition before you buy.
Related reading
Some links are affiliate links: we earn a small commission if you buy, at no cost to you. It does not change what we list.