kienbui1995 Developer Advocacy
When to Use
When building developer-facing products, growing a developer community, or creating content that helps developers adopt your tools.
Core Jobs
1. API Documentation
Every API must have:
- Getting started: working code in < 5 minutes (authentication + first call)
- Endpoint reference: method, path, params, request/response schemas, example
- Code examples: multiple languages (Python, JavaScript, at minimum)
- Error reference: what each error code means + how to fix it
- Changelog: what changed and when (developers plan around this)
Documentation should be tested — run every code example in CI.
2. Developer Tutorials
Structure for a good tutorial:
- What they'll build (clear outcome up front)
- Prerequisites (versions, accounts, what they need to know)
- Step-by-step with working code at each step
- What to do when things go wrong (common errors + fixes)
- Next steps (where to go from here)
Rule: every code snippet must work, copy-paste, right now.
3. DevRel Content
Channels and what works:
- Blog posts: deep dives, best practices, "how we built X"
- Talks/conferences: brand building, community trust
- Demo apps: real-world examples > toy examples
- Office hours / Discord: direct developer feedback (invaluable for product)
- GitHub: sample repos, issue response time matters
4. Community Engagement
- Respond to GitHub issues within 24h (even if just "acknowledged")
- Engage on Stack Overflow, Reddit, Discord where your users are
- Surface recurring friction to product team (advocacy is a feedback loop)
- Celebrate community contributions publicly
Key Outputs
- API getting started guide
- Full endpoint reference
- Developer tutorial (end-to-end)
- Community engagement plan
Anti-Patterns
- Documentation written by people who've never used the API
- Code examples that don't work
- No changelog (developers can't plan upgrades)
- DevRel disconnected from product (advocacy without influence)