What is Developer Experience and why you should care
Length:
8 min
Published:
October 27, 2020

Technology moves fast. New products and frameworks show up every year, and the needs of users change with them. It is easy to assume your own developers, or the developers using your services, will make do with whatever you give them. To be honest, that holds true only up to a point.
If you struggle with developers who underperform or who keep leaving, this article is for you.
We will look at what Developer Experience is, how it changes the way your business works, and why its principles are worth adopting.
What is DX
Developer Experience means giving developers everything they need to focus fully on doing their best work. It splits into two sides: internal and external.
Internal DX
Internal Developer Experience streamlines the processes inside a development team and removes the obstacles developers run into. It covers these areas:
- Cutting activities developers find neither interesting nor necessary for the job (for example, getting rid of meaningless meetings),
- starting new ones (such as pull requests, code reviews, and many others),
- removing bottlenecks in development (such as automated deployments),
- using the right tools for the job (from agile ceremonies for running projects to the right IDEs for the work),
- and a healthy team dynamic (a non-toxic environment and regular feedback between colleagues).
Who does a better job: someone in a welcoming, supportive environment, or someone who can barely get excited about the work? You already know the answer. Developers are one of the most heavily scrutinized groups on any project, so it matters that they feel their work is important and helps others.
Focusing on your development team directly cuts the costs of turnover and the resources you burn when the team is understaffed.
External DX
External DX is the opposite side: how easy your tools are to use for the developers who consume them. Those tools range from IDEs and frameworks to the APIs of services they integrate and the SDKs they build into their applications. Each part has its own metrics, but the most important and most common one is usability: how hard it is to get started, how easy the daily work is, and how good the troubleshooting and support are.
How does it relate to UX
If this sounds like UX, you are partly right.
Both aim for the best possible use of a product or service. Users of Revolut, for example, want the product to be easy to use and the experience to be smooth. Developers who might use your product or work in your company want the same thing.
In other words, developers are users too.
They use a lot of tools every day, and they consume your culture and your management's decisions.
Users who do not enjoy a product stop using it and find a better alternative. The same goes for developers. No one wants to work in a company with a toxic culture or use a product with terrible documentation.
But why should I care?
The term UX first appeared in the mid-90s, but it took off in 2007, when Donald Norman used it in an interview. From then on, its popularity grew and so did the push to apply it in everyday life.
If you remember web applications from before roughly 2010, you remember how hard they were to use. Working with them often made no sense to the people who had to. Companies that brought UX into their applications survived. The others did not.
Any new company without the UX gene in its DNA will fail, no matter how good the idea behind it is.
The pool of developers is small, so hiring qualified ones only gets harder. If developers dislike your product, they simply will not use it. They tell their friends, and word of mouth kills it before you even notice.
It is even worse when the talent you already have decides to leave. You lose not only the know-how of someone who built your systems. You also pay over time: the sunk cost of hiring a replacement, onboarding them, and carrying them up the learning curve of your processes and systems.
Look at the rise of UX, and it should be clear that DX has the potential to be just as big a few years from now.
Why you should get on board as soon as possible
Jumping on DX early gives you a competitive edge: lower developer turnover and a better product for your users, which leads to better sales and revenue.
Companies that failed to adapt or improve their services fell behind (Nokia, Kodak, MySpace, or the Walmart redesign that cost them billions of dollars). The ones that innovated, Apple being the obvious example, grew into success over time.
The inner workings of your company and the service you give your end users (developers) go hand in hand. Together they lead to bigger sales and a better reputation in your field than your competitors have.
Examples of companies doing DX well
When it comes to great external Developer Experience, Stripe and Heroku stand out. Both aim directly at developers, who happen to be their end users, and both have mastered the craft of giving them a great experience. Just look at their documentation and integration flow, which even make sense to non-technical people.
On the framework side, Vue is worth a mention. It is an underdog among frontend frameworks, but people love it for its capabilities and the tools around the core libraries, such as the Vue CLI.
So, now that you know how much your company might be missing out on, will you get on board?
Learn more about DX Heroes services, pick up some DX knowledge, or just tell us about your own experience in the comments.
Want to stay one step ahead?
Don't miss our best insights. No spam, just practical analyses, invitations to exclusive events, and podcast summaries delivered straight to your inbox.