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.

Set a time budget

StageBooksPagesReadingAt 3 hrs a week
Getting started4≥ 820≥ 21 hrs≥ 7 wks
Doing the job61,63041 hrs14 wks
Senior and leading251013 hrs4 wks
All 3 stages12≥ 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.

  • Cover of Show Your Work!
    Start here

    Show 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 →
  • Cover of Made to Stick

    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 →
  • Cover of Presentation Zen

    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 →
  • Cover of Docs for Developers

    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.

  • Cover of Wired for Story

    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 →
  • Cover of Crossing the Chasm

    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 →
  • Cover of The Pragmatic Programmer

    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 →
  • Cover of Designing Web APIs

    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 →
  • Cover of Producing Open Source Software

    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 →
  • Cover of Don't Make Me Think, Revisited

    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.

  • Cover of Radical Candor

    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 →
  • Cover of The Manager's Path

    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.

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.