Developer Experience (DX) is the experience of using a developer tool or extending your product (meant for developers), API, open-source code, or just about anything that has to do with developers. It’s the equivalent of User Experience when the primary user of the product is a developer.
As a consultant who helps businesses understand developers, this term DX is thrown around a lot and probably heavily discussed. It’s fun to see how the definition changes based on the context of a project/company or thoughts of the company’s CTO.
Developer Experience…#
“What’s the first thing you think of when you think of “Developer Experience” (DX)?” — asked Chris Coyier on Twitter today.
And here’s what I shared…
In two words: “Less Friction”
- ✅ Less clicking
- ✅ More automation
- ✅ Zero or less configuration
- ✅ Great documentation (searchable)
- ✅ Dark mode. VSCode support. Next.js
…ok the last one there might be too close to my heart but all things considered, having a good DX can mean a lot of things to your company.
Developer Experience has a cost to it. Some companies, in an effort to improve DX around their products, sacrifice the User Experience (UX) whereas I believe there should be a good equilibrium between DX & UX. It’s what some people call the Trickledown Experience. A story for another day.
If you are on Craigslist looking to buy a bed. And you find a listing of a bed that’s free. You immediately think that there’s something seriously wrong with it. Bed bugs or part of a crime scene.
At the same time if you find a listing of a bed that’s USD 5000. Your mind goes, “oh boy; this bed must be amazing, how lucky are the people who get to sleep on it”. And you wonder…
DX works in a similar fashion. Just because you open-sourced an SDK doesn’t mean developers are going to fall heads over heels in love with your product. It’s an art. For that, you need help from a practicing artisan. Who knows what developers care about. Invest in that.
Ahmad Awais
