Developer Experience¹ is a term² with a self-declaring meaning — the experience of developers — but it eludes definition in the sense that people invoke it at different times for different reasons referring to different things. For instance, our own Sarah Drasner’s current job title is “VP of Developer Experience” at Netlify, so it’s a very real thing. But a job title is just one way the term is used. Let’s dig in a bit and apply it to the different ways people think about and use the term.
specific companies.People think of
I hear DX and Stripe together a lot. That makes sense. Stripe is a payment gateway company almost exclusively for developers. They are serious about providing a good experience for their customers (developers), hence “developer experience.” Just listen to Suz Hinton talk about “friction journals”, which is the idea of sitting down to use a product (like Stripe) and noting down every single little WTF moment, confusion, and frustration so that improvements can be made:
Netlify is like Stripe in this way, as is Heroku, CodePen, and any number of companies where the entire customer base is developers. For companies like this, it’s almost like DX is what UX (User Experience) is for any other company.
specific technologies.People think of
It’s common to hear DX invoked when comparing technologies. For instance, some people will say that Vue offers a better developer experience than React. (I’m not trying to start anything, I don’t even have much of an opinion on this.) They are talking about things like APIs. Perhaps the state is more intuitive to manage in one vs. the other. Or they are talking about features. I know Vue and Svelte have animation helpers built-in while React does not. But React has hooks and people generally like those. These are aspects of the DX of these technologies.
Or they might be speaking about the feeling around the tools surrounding the core technology. I know create-react-app is widely beloved, but so is the Vue CLI. React Router is hugely popular, but Vue has a router that is blessed (and maintained) by the core team which offers a certain feeling of trust.
> vue create hello-world
> npx create-react-app my-app
around the technology.People think of the world
Everybody thinks good docs are important. There is no such thing as a technology that is better than another but has much worse docs. The one with the better docs is better overall because it has better docs. That’s not the technology itself; that’s the world around it.
Have you ever seen a developer product with an API, and when you view the docs for the API while logged in, it uses API keys and data and settings from your own account to demonstrate? That’s extraordinary to me. That feels like DX to me.
“Make the right thing easy,” notes Jake Dohm.
That word, easy, feels highly related to DX. Technologies that make things easy are technologies with good DX. In usage as well as in understanding. How easily (and quickly) can I understand what your technology does and what I can do with it?
What the technology does is often only half of the story. The happy path might be great, but what happens when it breaks or errors? How is the error reporting and logging? I think of Apollo and GraphQL here in my own experience. It’s such a great technology, but the error reporting feels horrendous in that it’s very difficult to track down even stuff like typos triggering errors in development.
What is the debugging story like? Are there special tools for it? The same goes for testing. These things are fundamental DX issues.
offerings.People think of technology
For instance, a technology might be “good” already. Say it has an API that developers like. Then it starts offering a CLI. That’s (generally) a DX improvement, because it opens up doors for developers who prefer working in that world and who build processes around it.
I think of things like Netlify Dev here. They already have this great platform and then say, here, you can run it all on your own machine too. That’s taking DX seriously.
Having a dedicated CLI is almost always a good DX step, assuming it is well done and maintained. I remember WordPress before WP-CLI, and now lots of documentation just assumes you’re using it. I wasn’t even aware Cloudinary had a CLI until the other day when I needed it and was pleasantly surprised that it was there. I remember when npm scripts started taking over the world. (What would npm be without a CLI?) We used to have a variety of different task runners, but now it’s largely assumed a project has run commands built into the
package.json that you use to do anything the project needs to do.
Melanie Sumner thinks of CLIs immediately as core DX.
coding.People think of the literal experience of
There is nothing more directly DX than the experience of typing code into code editing software and running it. That’s what “coding” is and that’s what developers do. It’s no wonder that developers take that experience seriously and are constantly trying to improve it for themselves and their teams. I think of things like VS Code in how it’s essentially the DX of it that has made it so dominant in the code editing space in such a short time. VS Code does all kinds of things that developers like, does them well, does them fast, and allows for a very wide degree of customization.
TypeScript keeps growing in popularity no doubt in part due to the experience it offers within VS Code. TypeScript literally helps you code better by showing you, for example, what functions need as parameters, and making it hard to do the wrong thing.
The difference between a poor developer environment (no IDE help, slow saves, manual refreshes, slow pipelines) and a great developer environment (fancy editor assistance, hot reloading, fast everything) is startling. A good developer environment, good DX, makes you a better and more productive programmer.
compare it to user experience (UX).People
There is a strong negative connotation to DX sometimes. It happens when people blame it for it existing at the cost of user experience.
Equally as often, people connect developer experience and user experience. If developers are empowered and effective, that will “trickle down” to produce good software, the theory goes.
Worst case, we’re in a situation where UX and DX are on a teeter totter. Pile on some DX and UX suffers on the other side. Best case, we find ways to disentangle DX and UX entirely, finding value in both and taking both seriously. Although if one has to win, certainly it should be the users. Like the HTML spec says:
time.People think about
How long does a technology take to adopt? Good DX considers this. Can I take advantage of it without rewriting everything? How quickly can I spin it up? How well does it play with other technologies I use? What is my time investment?
This kind of thing makes me think of some recent experience with Cloudflare Workers. It’s really cool technology that we don’t have time to get all into right here, but suffice to say it gives you control over a website at a high level that we often don’t think about. Like what if you could manipulate a network request before it even gets to your web server? You don’t have to use it, but because of the level it operates on, new doors open up without caring about or interfering with whatever technologies you are using.
Not only does the technology itself position itself well, the DX of using it, while there are some rough edges, is at least well-considered, providing a browser-based testing environment.
A powerful tool with a high investment cost, eh, that’s cool. But a powerful tool with low investment cost is good DX.
don’t want to think about it.People
They say the best typography goes unnoticed because all you see is the what the words are telling you, not the typography itself. That can be true of developer experience. The best DX is that you never notice the tools or the technology because they just work.
Good DX is just being able to do your job rather than fight with tools. The tools could be your developer environment, it could be build tooling, it could be hosting stuff, or it could even be whatever APIs you are interfacing with. Is the API intuitive and helpful, or obtuse and tricky?
Feel free to keep going on this in the comments. What is DX to you?
- Are we capitalizing Developer Experience? I’m just gonna go for it.
- Looks like Michael Mahemoff has a decent claim on coining the term.
Not to make it a language battle, and I guess I’m biased, but when it comes to developer experience I don’t think ruby should be left unmentioned. The language was designed around developer happiness. See also The rails Doctrine, a popular ruby framework.
python also has beautiful ideals but the syntax is so bad it’s a joke
ruby isn’t much better from what I’ve seen actually
For me, Shopify has the worst DX. I am still shocked that you cannot even minify the HTML output, not to mention the lack of the support for Git, for example. The best we could do is to use tools like Theme Kit, which is presented as Shopify’s GitHub, and that makes me cry little, where you need to wait for sync from local to remote code to see changes.
I might be wrong here, and I would appreciate it if anybody has information that I am not correct here.
People compare it to user experience
hierarchy is fine, but something’s still wrong.. (w3c)
from my experience:
– users usually don’t even know who is the author
– authors usually hide behind “we”, “community”, team etc.
– browser implementors don’t listen to authors
– spec makers don’t bother to check if the implementor listens to authors
because all of that:
– app authors listen to implementors in the first place
so, you get DX over UX
my point is that hierarchy should be followed and controlled by it’s members for the better world..
“In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors”
this should apply to every product that aims to be good
users feed you, make them happy!
Nice article! It is true, that often we developers are mixing our “developer experience” too much with what we think is the “user experience”.
I think that this is a heavy weight topic that we as developers have not been able to formulate properly.
For the every day, average manager, company leadership developer experience is of the least of priorities. “Why, we are paying you a lot, so shut up and code” they say, since there are no hard numbers, nor deep thought behind why a company should invest in it.
But developer experience is also productivity and productivity means cold hard cash usually.
The other ramification is the adaptability of certain technologies. For example I never succeeded to install Java and fire up a repo in Java without extensive googling the error messages. Personally I would never choose it for my own projects. Compare it with the ease of installing node and running
So the next revolution is taking DX seriously. It will make and break languages and platforms and infrastructure.
FWIW, I believe truly good DX always takes the end user into account. If something about the developer experience causes terrible performance or causes the UI to be inaccessible, this this a terrible experience regardless of how “nice” the developer’s experience is. Good DX should make the “right thing” default or extremely easy and make the “wrong thing” difficult or impossible, and I think we as developers should accept no less.