Developer Experience: Does it Matter?

Over the last few years, more and more developers and researchers look at developer experience, that is how developers think about, feel about, and value their work. This is important because for example friction that developers experience through cumbersome tools, or processes and policies that get into their way, reduce developer experience drastically, and arguable lead to a loss of productivity.

But is that so? Does developer experience have an impact on performance, productivity and even for on the ability of an organization to meet its goals?

In a recent study, we investigated exactly this question and shed light on whether measuring and improving DevEx is important for outcomes related to developers themselves (individuals), their teams, and their organization. Let me summarize the paper for you, or read the full version here.

Friction in a developer’s day is abundant

Software developer faces numerous distractions and unclear tasks on an ongoing basis: Long-turn around times for code reviews, flaky test that fail the pipeline, unclear ticket description. All those problems are well-known by many developers and lead to frustration and inefficiency. Yet even larger issue in the development lifecycle that lead to inefficiencies and fill a developers day with unnecessary obstacles, are often overlooked by upper management.

Management struggles to grasp DevEx

Developer experience (DevEx) is a direct concept that allows to detect, measure, discuss and improve such problems in the software development lifecycle. Yet, despite its importance, DevEx faces skepticism from some business stakeholders, and developers and developer experience or platform teams often struggles to get management to commit to improving DevEx. Especially management that isn’t that familiar or involved with programming and the problems developers face asks whether DevEx is crucial and a must for investment, or if it is just a nice to have, that can be ignored.

Quantifying DevEx Outcomes

Thus, in this research we investigate outcomes of DevEx on individual, team, and organizational dimensions.

  • Developer Outcomes: These include job performance, creativity, and learning, with the premise that improved work design leads to better outcomes for individual developers.
  • Team Outcomes: Focused on the quality of the system the team works in, including aspects like code quality and technical debt.
  • Organization Outcomes: These outcomes include retention, innovation, profitability, and the organization’s ability to meet its goals.

Model of DevEx

For this study, we introduce a model for understanding and measuring DevEx, that follows closely the framework we introduced in our earlier work here. It conceptualized DevEx through three dimensions:

  • Flow State: Refers to a mental state of deep immersion and focus in work.
  • Feedback Loops: The speed and quality of information in a system used as input to another part.
  • Cognitive Load: The amount of mental processing required for a developer to complete a task.

DevEx makes an Impact

Our study presents evidence that improving DevEx has positive outcomes not just for developers but also for teams and organizations.

  • Developers who have a significant amount of time for deep work feel 50 percent more productive compared with those lacking in dedicated focus time.
  • When developers feel engaged, they also feel they are 30 percent more productive, compared with developers who find their work boring.
  • If the code is understandable developers feel 42 percent more productive than developers that indicate their code base is hard to understand.
  • Developers who find their tools and work processes intuitive and easy to use feel they are 50 percent more innovative compared with those with opaque or hard-to-understand processes.
  • Developers who report fast code-review turnaround times feel 20 percent more innovative compared with developers who report slow turnaround times.
  • Tight feedback loops have another positive outcome. Teams that provide fast responses to developers’ questions report 50 percent less technical debt than teams whose responses are slow.

Where to go from here

It emphasizes the need for organizations to understand and invest in DevEx.

Concrete steps for advocating such DevEx investment include:

  • collecting data on the current DevEx,
  • setting goals based on this data,
  • preparing teams for success, sharing progress, and continuously revisiting and refining the approach.

To read the complete study, please visit the ACM website here.

This article first appeared on Last updated: January 19, 2024

Profile picture of Michaela Greiler

Written by Dr. Michaela Greiler who is obsessed with making code reviews your superpower. Learn more about her workshops.