Developer experience: What is it and why should you care?

Software development is a UX problem

Developer experience—DevEx for short—is the discipline of treating the developer as the end user. It covers the systems, tooling, processes, and culture that surround software development, asking not just whether work gets done but whether the environment actively helps developers get it done well. GitHub’s Jonathan Carter draws a deliberately mundane parallel: he used to avoid vacuuming until he realized the chore was only painful because the vacuum lived on the wrong floor. Move the friction, and the behavior follows. “When we construct the experience to empower the desired behavior naturally and effortlessly,” he says, “we get a great outcome.”

Carter’s colleague Idan Gazit puts the developer’s stake in the ground more starkly: “Building software is like having a giant house of cards in our brains. Tiny distractions can knock it over in an instant.” Development work is notoriously fragile to interruption. DevEx work tries to keep the cards standing by reducing the distance between what a developer intends and what the environment lets them accomplish.

DevEx is an old problem we are only now naming

The industry has been slow to treat developer experience as a first-class concern, even as the complexity of the average workflow has exploded. Teams now assemble software from a sprawling landscape of open source libraries, package managers, languages, and services—many of which compete, none of which document their interactions well. As analyst firm RedMonk puts it, developers have unprecedented access to technology and DevOps tooling, but they are “on their own” figuring out how it all plugs together.

The result is a fragmented experience that forces engineers to constantly learn new tools, chase new APIs, and piece together context from multiple disconnected sources. Eirini Kalliamvakou, a staff researcher at GitHub, makes the case for taking a step back. Because collaboration is the multiplier across every part of a developer’s workflow, the holistic experience needs to be “collaborative and smooth every step of the way.”

Why DevEx now shows up in the CFO’s deck

DevEx stops being a developer-happiness initiative and becomes a business metric once you frame software development capacity as the production line of modern business. “In most contexts, software development capacity is the limiting factor for innovation,” says Greg Mondello, a director of product at GitHub. “Improvements to the effectiveness of software development are inherently valuable.” With builds and deployments still becoming more complex, DevEx is also a competitive differentiator within an industry: better developer environments mean teams move with less manual overhead and outpace rivals across every vertical.

The numbers from both analyst research and internal tooling agree. Teams that invest in DevEx practice report nearly universal benefit. In Forrester’s opportunity snapshot, for example, 77% of those surveyed saw shorter time to market and 85% saw impact on revenue growth by making code, build, and ship processes easier for developers.

What good DevEx actually looks like

On the ground, DevEx feels frictionless. Developers have the information they need, move between heads-down focus and group collaboration with ease, and rarely have to fight the toolchain. That is aspirational: most developers today burn time on build queues, flaky systems, out-of-date documentation, and interruptions that shatter the mental models they are juggling. A good experience anticipates those failure points before a human trips over them.

Kalliamvakou warns that “ideal” DevEx means “no friction at all, or minimal delay in completing tasks,” and that the discipline must center on the developer. “You can’t improve the developer experience with developers out of the loop,” she stresses.

How to measure something subjective

There is no standard industry yardstick for DevEx yet. Teams frequently turn to the DevOps Research and Assessment (DORA) metrics for signals that already exist in their pipelines:

• Deployment frequency (DF): how often your team ships software
• Lead time for changes (LT): wallet-to-wallet time from commit request to prod deploy
• Mean time to recovery (MTTR): the average window to recover from failure
• Change failure rate (CFR): the share of changes that break the build or the service

Those measure process efficiency, but they do not measure what it feels like to do the work, so having a few human signals in the mix helps. Carter suggests tracking the time it takes a new hire to make their first contribution—a strong sign that a developer found the context they need and felt empowered to act. He treats customer response time as a useful proxy too: “No amount of morale boosting or being friendly makes up for the fact that people want to feel valuable.”

The workflow event everyone knows too well—an approval queue that swallows a pull request for two days—probably shows up in none of those data points without a deliberate survey. Kalliamvakou argues that effective DevEx teams run periodic feedback loops with developers because infrastructure metrics cannot tell you about the anxiety of a flaky CI build. “Without these surveys,” she warns, “even the most sophisticated telemetry is incomplete and potentially misleading.”

Improving DevEx without breaking what you have

Treating DevEx like a product improvement means methodical work: start with discovery, find the pinch points, and iterate with user feedback. Then be prepared to trade one source of friction for another. Research may turn up a painful bottleneck in a slow old build script. Replacing it can reduce build wait times, but any change in process risks breaking collaboration or focus in some other place.

The engineer’s rule of thumb: start from a known snapshot of where things hurt. Many organizations formalize this work with a dedicated DevEx team that exists to understand and improve developer sentiment and to watch out for regressions introduced by “improvements.”

Finally, align on what the optimal target looks like. Mondello points to a positive case study from his own employer: “GitHub’s invention of the pull request was a pivotal moment” in design, structuring reviews so that collaboration is part of the coding flow. As more code is authored or modified by AI, he argues collaboration becomes even more load-bearing: “It’s the only way to ensure that AI-generated code is solid.” If a team’s pull request flow is a black box, its code review quality suffers no matter who—or what—wrote the first draft.

Organizations that ignore DevEx will, in Kalliamvakou’s view, quietly fall behind. Those that take it seriously build better systems for retention, velocity, and security. Friction, after all, is also where innovation goes to die, and the pull request isn’t the only thing worth waiting on: a two-day wait feels like an eternity to the author of a feature that already works on their machine. As Gazit frames it, the point is to intentionally stack the environment “and confidently enable developers to stack their cards ever higher.”

Generative AI’s role in developer experience

Generative AI is poised to reshape DevEx by accelerating the path to high-quality code. As models improve and tooling adapts to how developers actually work, AI assistance is expected to evolve beyond code and pull request suggestions into broader workflow recommendations.

“As models get better and more functionality is built around how developers work, we can expect AI to suggest whole workflows,” says GitHub’s Kalliamvakou. The payoff, she notes, is that AI could eliminate “major disruptions, delays, and cognitive load that developers previously had to endure.”

GitHub’s Mondello frames this shift in terms of capability rather than convenience. “Generative AI will unlock the potential for developers to leapfrog large amounts of the software development process,” he says. In this view, DevEx moves beyond eliminating toil and friction toward enabling developers to make substantial strides in their workflows.

Faster code creation, however, forces attention on the rest of the delivery pipeline. Organizations will need to accelerate build and test cycles and optimize production pipelines to keep pace with AI-generated code. Mondello points to GitHub Copilot as an early proof point, and to GitHub Copilot X as the next step in applying generative AI across the entire software development lifecycle.

The takeaway

DevEx has become a central factor in engineering speed and business outcomes. Developer satisfaction and empowerment underpin software success in every sector, and their importance is only set to grow. For more data on what developers value, see GitHub’s developer experience survey.