A while ago Sarah Drasner wrote a great post on her view of Developer Experience (DX) at Netlify and how that manifests in roles like Developer Advocate. I felt prompted to write a bit about how I, a consumer of DX, experience DX and what good DX is to me. Although I’m not a Developer Advocate, I interact with advocates and evangelists daily and feel strongly that any company that produces developer tools, an API, or even open source projects need to leverage their skills.

DX resolves to three important questions to me:

  • Is it easy? Does this technology solve a problem I have better than I’m currently doing it.
  • Can I get help? If I have a problem, can I talk to someone? Will I talk to someone helpful or someone shitty?
  • Is the community healthy? If I do go all-in on this, is the community toxic or nice? If applicable, do good community extensions exist?

The first question, “Is it easy?” comes down to good documentation which takes time and money to create. If a company can create good docs, tutorials, videos, livestreams, etc and they can convince me that this is a smidge better than my current way, sells me more than bells and whistles ever would.

The second question, “Can I get help?” is a bit tricky and may sound like a privileged Karen in a McDonald’s. What I mean is this: If I have a question about something (general or specific), is there someone who can answer my question? Are people in or around the core team accessible? What degree of separation is there between me and the people who make this? Sometimes asking the abyss for an answer works, but sometimes people copy-paste the first Google result back at you.

The third question, “Is the community healthy?” has a lot of ramifications. I think Developer Advocates play an important role in setting the behavior standard for any community surrounding a project or technology. Hire assholes, you get assholes. For a long, long time (e.g., Linux). Hire good, helpful people, you get good and helpful people hanging around your technology. I think if you don’t focus on healthy community engagement, you open the door for shitlords to rule the roost and cement the culture.

I could provide a dozen anecdotes on each of those tenets, highlight dozens of people who are doing it well, but instead of spinning boring tales of times past, here’s an old Kevin Kelly quote I love:

A tool is an opportunity with a handle.
— Kevin Kelly

If you’re in the business of building tools, build the tool but make sure the handle is as appealing as possible. Make it seem easy, make sure the people who use it are helpful, and pay people to stand in the proverbial Costco aisle to show off your tool. In the modern world of influencers and content creators, it’s never been more important.

And one final thought, it’s easy to conflate “developer experience” with “developer gratification”. Developers are the customer, after all, and their satisfaction is important but more important than that is to acknowledge that a lot of our tooling also effects the End User. Consideration of End Users is a key part to any good developer experience. What are the tradeoffs for the User? Not in an unquantifiable “it helps developers ship products faster” brand of hand-waving, but in a transparent way that acknowledges the tradeoffs being made. Written into the ethos of the Web is “Users over Authors over Implementors…” and I believe we must preserve this principle even in our tools. Otherwise we’re building an internet for developers and not an internet for everyone.

Thanks Jim Nielsen for reviewing a draft of this post.