Have you ever found a code snippet in a tutorial, spent an hour trying to make it work, only to realize it’s using a deprecated library from 2019?
We’ve all been there.
I recently sat down with Sam Bellen, Principal Developer Advocate at Auth0, for the first episode of the Making Software podcast. We talked about the "diplomatic" nature of Developer Relations, the controversy of "selling" to developers, and why we need to stop treating demo code like a second-class citizen.
Here are the key takeaways for every developer, whether you’re looking to break into DevRel or just want to build better software.
1. DevRel: Part Engineer, Part Diplomat 🤝
Sam and I agreed on a unique definition: DevRel is a mix of developer and diplomat.
As a developer, you’re used to talking to Product Teams to understand requirements. In DevRel, that flow often reverses. You are the "voice of the developer" inside the company.
"It’s building relationships with the product teams... at a certain point, they will start trusting that what you’re telling them is actually valuable feedback instead of just randomly pinging people on Slack." — Sam Bellen
The Lesson: If you want to influence a product's roadmap, don't just throw bugs over the fence. Build a relationship with the people making the product. Trust is the currency of influence.
2. Authenticity > Sales 🚫💰
Developers are notoriously skeptical of being "sold" to. We can smell a marketing pitch from a mile away. Sam’s approach? Lead with the problem, not the product.
Instead of saying, "Use our auth tool because it's great," talk about how hard it is to implement DPoP (Demonstrating Proof-of-Possession) or Passkeys manually.
When you illustrate the complexity of a problem, the solution (your product) becomes a natural part of the conversation rather than a forced advertisement.
3. Treat Demo Code as Production Code 🛠️
This was Sam’s biggest take: Any code you write (even a tiny sample for a blog post) should be treated as production code.
If a vulnerability is found in a framework, DevRel teams should be the first to update their samples. Why? Because that sample is often a developer's first "touchpoint" with your tech.
Why this matters:
- Security: Developers often copy-paste samples directly into their projects.
- Trust: If your "Quick Start" doesn't work out of the box, you've lost the user.
- Maintenance: Technical debt exists in docs, too. Set aside time (Sam recommends monthly) to audit your repos for deprecated APIs.
4. Get Your Hands Dirty with the Spec 📖
Sam has a "superpower": he actually likes reading technical specifications. While most of us fall asleep reading an RFC, Sam uses them to build visual tools that explain what’s happening "under the hood."
"In order for me to explain something... I build it myself. Not a clone of the product, but a demo that implements the topic. I make loads of mistakes, get lots of errors, and eventually, I figure out what's happening."
The "Aha!" Moment: You don't truly understand a tool until you've tried to build the logic it simplifies.
Summary: Two Steps to Better Developer Experience
If you’re an engineer looking to improve the DX (Developer Experience) of your project today, start here:
- Listen to your DevRel team: They aren't just "social developers." They have the technical baggage and the community feedback to tell you what’s actually broken.
- Stop "dropping" code on GitHub: Don't just create a repo and ignore it. If it’s public, it’s "production" for someone else.
🎧 Listen to the Full Episode
Want to hear the full conversation about guitars, Passkeys, and the early days of DevRel?
Listen to the full episode here or in your platform of choice.
What’s your take? Should demo code be held to the same linting and security standards as the core product? Let’s talk in the comments! 👇
Top comments (0)