Understanding developer experience is vital when you want to improve the work engagement and productivity of the developers within your engineering organization. We'll cover what developer experience is, why it is important, and how to measure and improve it.
Developer experience (DevEx, DX) is the overall experience of a developer when they are building software in a team. It describes how developers perceive, feel about, and value their work.
The three components of developer experience are:
In research these three components are known as cognition, affect, and conation. In this guide we’ll keep things practical and refer to them as infrastructure, feelings about work, and the value of work.
Improved developer experience boosts both the productivity and work engagement of the engineers in your organization. Streamlining your development processes and tools helps developers complete their tasks faster with less pain. People with high engagement are more likely to produce better quality software, collaborate better, and have lower turnover rates.
Reseach has shown that human factors are the most critical factors affecting software development productivity and quality. Developer experience gives you a lens to your engineering organization that allows you to improve both the human factor as well as the tools and methods you use — ultimately leading to better business performance.
If you’re just getting started, talk to your managers, team leads, and developers. What are the top 5-10 things causing a bad experience for your developers and breaking their flow? Select the most impactful problems to solve and set a measurable goal.
At this stage, companies commonly start improving things like compile times or number of flaky tests and measure things related only to their development infrastructure.
In the long run, you need to be able to address bigger problems like company culture or the way you structure your teams. To achieve this, you need to measure all three components of developer experience: infrastructure, feelings about work, and value of work. This requires multiple measures from multiple different angles. Specifically, you should track both engineering metrics as well as developer feedback.
For engineering metrics, common things to measure include wait times, DORA metrics, and your investment balance. Wait time metrics include compile times, test suite duration and flakiness, CI/CD build times, pull request cycle time, and issue cycle time. DORA metrics help you achieve and maintain continuous delivery. Tracking your investment allows you to balance feature work and developer experience improvements. (More on these metrics below.)
Developer feedback allows you to measure satisfaction and wellbeing. It also gives context to complex, nuanced problems like cross-team collaboration or changes in how teams work. Developer feedback is invaluable when ensuring that your engineering metrics reflect reality.
If your teams have a high level of psychological safety and trust, 1-1s and retrospectives are the best ways to get genuine and timely developer feedback. It should also be easy for developers to report issues when they face them.
You can — and should — also run developer experience surveys, but if you run them too often with too many questions, people won't reply. So they’re practically always a lagging indicator, and you should try to find ways of tracking more real-time signals whenever you can.
Improving developer experience is a big topic, but this section includes five of the most impactful things you can do.
You will notice that none of the suggestions is linked to just a single component of developer experience. The components are intertwined, so changes in, for example infrastructure will affect how people feel about and value their work.
The number one driver of developer experience is flow. And the number one enemy of flow is unnecessary wait times and interruptions. Flow state allows developers to focus on their work, get a sense of accomplishment, and enjoy tackling challenging problems. Unnecessary wait times and interruptions make developers frustrated and unproductive.
Common causes preventing developer flow are poor developer tooling, impractical team processes, and unproductive company culture. Examples include flaky tests, slow code reviews, and wasteful meetings. The larger your organization gets, the more things can break people’s flow.
To tackle wait times and interruptions in your development tooling, you analyze what happens when developers write code and run your CI/CD pipeline. How long does it take to compile code, run tests, or deploy to production? The wins here are often small (seconds or minutes), but they have substantial compounding effects since they happen so frequently.
When analyzing the flow of developing features end-to-end, you need to understand your lead times, most commonly, issue and pull request cycle times. How long does it takes to ship a feature from start to finish and for code to get from the first commit to production (to your customers)? What interrupts developers when they try to complete their tasks? Common issues include poor collaboration, working with too large pull requests and stories, and not agreeing on ways of working together.
Tackling wait times is an iterative process where you improve things step-by-step. You should:
Nothing demonstrates the importance of developer experience like a chaotic working environment full of breaking tools, bugs, and constant firefighting. A mistake many organizations make is trying run their engineering organization as a feature factory with 100% efficiency. As a result, they’re overwhelmed with managing complexity and struggle to keep the lights on.
Instead of creating chaos, you want to ensure developers have a healthy environment to build and maintain features. To achieve this, you need to track your investment balance. It lets you see where your time goes and continually invest in paying back technical debt.
The investment balance above uses a categorization originally developed at Dropbox that divides work into four categories based on its impact: “building new stuff,” “improving things,” “improving developer productivity,” and “keeping the lights on” (KTLO).
Categorizing your work into these buckets allows you to:
Continuous deployment practices have a proven relationship with better developer experience. The DevOps Research and Assessment (DORA) team’s studies have shown that teams that ship consistently are more motivated, ship higher-quality code, have less deployment pain and burnout, and have higher levels of job satisfaction.
To make deployments fast and safe:
Most developers have experienced it: Unclear goals and requirements. Unreasonable deadlines. Arguments over roadmap and priorities. High-priority task overriding everything else – no one knows why. Subpar product outcomes as problems are half-solved.
Product management is a common source of discontent among developers. A solution many organizations employ is adding more processes and formal roles. More people and layers between the customer and the developer. This is a dead-end.
The better option is to build empowered product teams that own the customer experience of a feature or parts of the product end-to-end. These teams have higher autonomy, grasp the impact of their work, and encounter fewer blockers. These are all things that contribute to great developer experience.
To create empowered teams:
You can have an office full of developers with the fastest possible development environments shipping very little code. Even if they are cranking a ton of code, they might not care about building the right thing. This is where work engagement comes into play.
Developers with high engagement are persistent, dedicated to work, and want to ship quality software. They are proactive and willing to support the rest of the organization. They are also the most likely people do great work even when your developer experience is still lacking.
High work engagement stems from the right balance of stimulation (cognitive load, challenges, and stress) and pleasure (feelings of success, learning, purpose, and connectedness). When people have the right amount of stimulation and enjoy their work, they become excited and engaged.
To drive great developer experience through work engagement, you should:
Understanding developer experience is vital when you want to improve the lives of the developers in your teams. Having a systematic approach to improving developer experience will help you improve both the work engagement and productivity of your developers and, as a result, improve the business performance of your organization.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
