How technical do I need to be to be credible with developers?
Your progress in this module0%
0 of 7 steps · 0 of 1 Compass Challenges complete
Step 1 · Learn
How technical do I need to be to be credible with developers?
You don't need to be the best engineer in the room. You need to be credible: able to build a working demo, read and debug other people's code, use the same tools your audience uses, and talk about production without hand-waving.
This module is a checklist of that baseline. If you come from engineering, skim it, find your gaps (cloud? issue triage?) and move on. If you don't, this is the most important module in the roadmap. Budget real time for it and build things as you go. Reading about Git is not the same as resolving a merge conflict at 11pm before a talk.
Topic 1 of 6
Basic Programming Skills
Pick one language and get genuinely comfortable before spreading out. For most DevRel roles, JavaScript/TypeScript or Python is the safest choice because they are the most common languages in tutorials, SDKs and developer communities. If your target company's product is Go-, Rust- or Java-centric, follow the audience.
"Comfortable" for DevRel means you can:
Build a small app from scratch that calls an external API and handles errors
Read an unfamiliar codebase and find where something happens
Debug with a debugger or logs rather than guessing
Write code that is clear enough to teach from: good names, small functions, comments that explain why
Install dependencies, manage environment variables and run tests
Your code will be copied by thousands of people, so readability beats cleverness. The best way to learn is to build small, complete projects and explain each one in a short post. You're practising programming and DevRel at the same time.
If you're starting from zero, CS50 builds real fundamentals; freeCodeCamp and The Odin Project are project-based paths into web development.
Key takeaways
Go deep in one language first — usually JavaScript/TypeScript or Python
Aim for "can build, read, debug and teach", not "can pass a hard interview"
Write code that is easy to copy and understand; it will be
Most DevRel jobs involve a product that developers integrate through an API (a contract for talking to a service over the network) or an SDK (a library that wraps that API in a specific language).
Know these cold:
HTTP fundamentals: methods (GET, POST, PUT, PATCH, DELETE), status codes (200, 201, 400, 401, 403, 404, 429, 500), headers and JSON bodies.
REST: resources and URLs, pagination, filtering, idempotency, versioning.
Authentication: API keys, OAuth 2.0 flows, bearer tokens and never committing secrets.
GraphQL: a single endpoint where clients ask for exactly the fields they need. Know when it helps and when it's overkill.
Webhooks: the API calls you when something happens, which raises questions of signature verification, retries and idempotency.
Rate limits and errors: what a 429 means, backoff and retries, and reading error payloads.
SDKs: how they hide boilerplate (auth, retries, pagination), and why their ergonomics matter as much as the API's.
You should be able to explore an API with curl or Postman, then build the same thing with the SDK, and explain the difference to a beginner. That explanation is the job.
Key takeaways
Know HTTP methods, status codes, auth and error handling by heart
Understand REST, GraphQL and webhooks — and when each fits
Practise explaining raw API calls vs the SDK equivalent
Git is how code moves between developers. GitHub (and GitLab, Bitbucket) is where developer communities live. You'll use them for sample code, docs, open source contributions and your own portfolio.
Developers can tell within minutes whether someone is at home in a development environment. Live demos and streams make it very obvious.
Get comfortable with:
An editor/IDE: VS Code is the most common; know JetBrains IDEs if your audience is Java/Kotlin. Learn multi-cursor editing, search across files, the integrated terminal, the debugger and extensions.
The terminal: navigating, piping, environment variables, and a package manager (npm/pnpm, pip/uv, Homebrew).
Browser devtools: network tab, console and inspecting requests. Essential for debugging API demos.
API clients: curl, Postman or similar.
Containers: running a Docker image locally.
AI coding assistants: your audience uses them, so know their strengths, their failure modes and how your product shows up in them.
For demos: increase your font size, use a clean theme and profile, hide notifications, and keep your shell history free of secrets.
Key takeaways
Fluency in an editor, terminal and devtools is visible — and it builds trust
Know the tools your audience uses, including AI assistants
Set up a clean, readable "demo profile" before you present
Community feedback arrives as issues, forum posts, support tickets and chat messages. DevRel often owns the triage: turning noise into well-described, prioritised problems that engineering can act on.
Learn to:
Write a great bug report: environment, versions, steps to reproduce, expected vs actual, minimal code sample.
Triage: reproduce, label (type, area, priority, "good first issue"), deduplicate, close with kindness.
Link the loop: connect community reports to internal tickets, and tell the reporter when it ships. This closing step builds enormous goodwill.
Use the common tools: GitHub Issues and Projects for open source; Jira and Linear inside companies.
Good triage is one of the most underrated DevRel skills. It's a direct, visible feedback loop between developers and product.
Key takeaways
A reproducible bug report is a gift to engineering — teach your community to write them
Label, deduplicate and prioritise so signal survives the noise
Always close the loop with the person who reported it
Ship a "Hello World" demo developers can run in 5 minutes
The prompt
Build a small, runnable demo that integrates a real API, deploy it, and publish a short walkthrough. The goal is a time-to-hello-world under five minutes for someone who has never seen it.
This is a real DevRel deliverable. Sample apps like this are what advocates build every week.
The template
# <Project name> — <what it does in one line>
## Try it in 5 minutes
1. Get an API key: <link>
2. Clone and install
git clone <repo> && cd <repo> && npm install
3. Configure
cp .env.example .env # add your key
4. Run
npm run dev → open http://localhost:3000
## How it works
- `src/client.ts` — creates the API client
- `src/app.ts` — the one call that matters (explained)
## Common errors
| Error | Why | Fix |
|---|---|---|
| 401 Unauthorized | Missing/invalid key | Check .env |
## Next steps
- <link to the official docs for going further>