developer relations

I’ve had a few job titles for roughly the same job: developer success, developer relations, and now DX engineer. every few years someone renames it. the work is still helping developers get going with a product, and helping the company build something developers want to use in the first place.

most of what I’ve made over the years has been examples: small scripts, starter projects, and reference apps that wire a product into a real stack. developers learn by running something and poking at it, and a working example is the quickest way to give them that.

AI writes a lot of those examples now, which I’m happy about. the models still learn from somewhere, and a clear example in your docs is often what an assistant repeats back when someone asks how to use your product. bad examples get repeated too.

first impressions happen fast. a developer lands on your site and decides pretty quickly whether it’s for them. if it reads like a sales page, they’re gone. if the docs show one language, or none they use, they assume the product isn’t for them and close the tab.

AI agents size you up the same way. if your docs never show the product working with a framework, an assistant has very little reason to suggest you when someone asks how to do something in that framework. snippets in the languages people use, and docs that agents can read, help both audiences.

teaching keeps changing shape too. I’ve run workshops that took two or three hours to stitch a handful of tools together. an agent can scaffold that in a few minutes now. I still think there’s value in someone explaining why the pieces fit, because that’s the bit you need when something breaks.

I made GraphQL screencasts too, in the spirit of Ryan Bates and Railscasts. I stopped when I noticed I’d started learning from LLMs and docs myself, and assumed everyone else had as well. maybe I should’ve kept going a bit longer.

conference talks have shifted in a similar direction. the talks people want come from engineers who hit a problem and fixed it, explaining how. that’s always been the best kind of DevRel content anyway.

people still want a person. developers like having someone to ask for help, moan at, or jokingly bribe with a GitHub star to get their feature shipped on time. that person carries the feedback back into the product and tells everyone when it lands. I can’t see AI taking that bit over any time soon.

around 2023 the industry decided DevRel was dead. swyx called it a zero-interest-rate phenomenon: lots of hiring in the cheap-money years, then deep cuts when money got expensive. by late 2025 he was writing that DevRel was back. the roles that came through it were the ones where DevRel meant engineering, with people shipping SDKs, CLIs, integrations and examples themselves.

that’s where I think DX engineers fit best. I like to think of the role as an internal entrepreneur. if there’s a gap in the market and the product already has the building blocks to fill it, you get the right people together, work out what’s missing, and go and build it. every now and then one of those turns into a product.

it’s everyone’s job, really. DX works best as a habit across the whole company. an engineer working purely from tickets can only move as fast as the feedback reaching them. someone using the product every day, on side projects or their own tools, trips over the rough edges first and sometimes ships something nobody had thought to ask for. it’s a big part of why I think side projects are worth the time.

so call it developer relations, developer success or DX engineering. I’ll answer to any of them. the job is making a product developers want to use, and showing them how. you can see what that’s looked like for me over the years.