Every developer knows this scene by heart. A company ships a genuinely solid tool, backed by budget, a real team, and good intentions, and developers still don't adopt it. Meanwhile, a project that starts as someone's personal repo ends up in half the world's stack, pushed forward by nothing but a community that tries it, recommends it, and supports it for free in a GitHub issue at three in the morning.
That tension between product quality and adoption has a name that still sounds unfamiliar to a lot of people: developer relations, or devrel for short. Darío Macchi, developer advocate at Howdy, unpacked it as a guest on the Dynamic Devs podcast, and the conversation is worth breaking down because it touches something every senior developer eventually runs into: why we end up using the tools we use.
An Umbrella With Several Roles Under It
Darío has been in the industry for more than 25 years, and three and a half years ago he started building this role inside Howdy, where he was already working. Developer relations, as he describes it, is an umbrella that covers different positions. There's the developer advocate, who stands on the developer's side and uses the product from that vantage point. And there's the evangelist, a role closer to traditional marketing that peaked between 2010 and 2015 and has mostly fallen out of use since.
The difference, at bottom, comes down to which side of the table you're sitting on. An advocate defends the developer to the company. An evangelist defends the product to the developer.
Uncomfortable Feedback Gets Passed Along Too
The most interesting part of the conversation is how Darío describes the least glamorous piece of the job: taking in complaints, filtering them, and carrying them back to the company without softening them. If a developer raises a real problem, he can't play both sides, promising a fix and then never following up, or delivering the message half-heartedly. A developer's trust is the only currency he has, and losing it means losing the honest information he needs to do the job at all.
That honesty, more than any communication technique, is what separates devrel done right from marketing dressed up as a conversation between peers.
How a Tool Gets Chosen (and Why Technical Quality Isn't Enough)
Darío drew a sharp line between two worlds. In traditional software, choosing a tool comes down to concrete signals: solid documentation, clear examples, real activity in the repo, issues that actually get answered. If the last commit was a year ago and nobody replies when someone asks if the project is still alive, that signal outweighs any new feature.
With AI tools, the logic shifts. The industry still hasn't settled on stable working patterns (nothing like the design pattern catalog that came out of studying Java projects two decades ago), so communities end up forming tribes around their own methodologies, each one validating its own way of using a tool that's changing too fast to settle down.
One detail Darío points to: developers trust tools more when there's a real human face behind them. Someone visible, not just an anonymous technical team.
Fundamentals, Not Speed
On AI's impact on developer work, Darío was direct: it isn't replacing anyone, and he lives that reality daily working with his own agents. What's actually shifting is what separates someone getting real value from AI from someone just keeping pace with everyone else, and the answer isn't exotic: software engineering fundamentals.
He gave a concrete example. Generating new code with AI is fast and cheap, cheap enough to tempt you into skipping the review. So the question that matters isn't how much code you generate, it's how you make sure each change doesn't break what already worked. And the fix isn't new: automating functional tests against clear specs, something that was prohibitively expensive to maintain 30 or 40 years ago and, with specs now far more accessible, has become a cheap practice to run.
A Role Built Over Years, Not a Course
On what it takes to work in devrel, Darío was blunt: wanting it isn't enough. It takes real years of industry experience, technical knowledge of the product or field you're stepping into, and a harder skill to train: the willingness to put yourself out there publicly, hold a position, and take the heat when something doesn't land well.
On convincing a company to invest in the role, he admitted the hardest part: translating the effort into numbers. He mentioned someone who met Howdy at an event a year and a half ago and only just applied for a position, after several touchpoints in between. Good devrel is almost never measured in the quarter it happens in.
Outside the Stack
Away from the podcast, the conferences, and the feedback loops, Darío keeps a collection of bonsai trees native to Uruguay and a library of century-old botany books he tracks down in used bookstores. A detail that, without meaning to, sums up the job pretty well: growing something slowly, carefully, knowing the result only shows up over time.
