PaperlayerView exact revision on arXiv

Source-linked AI summary

An Actionable Framework for Understanding and Improving Developer Experience

Michaela Greiler, Margaret-Anne Storey, Abi Noda

arXiv:2205.06352v1cs.SE

TL;DR

Developer experience research has identified related constructs and factors, but the paper seeks actionable insight into what matters to developers and how improvement is constrained. Using interviews with 21 developers, it develops the DX Framework to organize factors, context, barriers, strategies, and coping mechanisms. The authors present it as a guide to understanding and improving developer experience, while noting that the framework does not establish causal relationships among its constructs.

  • Problem

    Prior work describes developer experience and related constructs, but which actionable factors matter, why, and how barriers may be overcome remain open questions.

    Source: §1 · p. 1

  • Method

    The authors conducted semi-structured interviews with 21 developers and iteratively coded the interviews to develop the DX Framework.

    Source: §1 · p. 1, §3.1 · p. 3

  • Results

    The DX Framework organizes experience factors and their contextual importance alongside barriers, improvement strategies, and coping mechanisms.

    Source: §1 · p. 1, §9 · p. 14

  • Takeaways & Limitations

    The framework is presented as a go-to reference for organizations seeking to understand and improve developer experience.

    Source: §1 · p. 1, §9 · p. 14

    The authors cannot claim correlations or causal relationships across the constructs captured by the framework.

    Source: §7.1 · p. 12

Abstract

from arXiv · show

Developer experience is an important concern for software organizations as enhancing developer experience improves productivity, satisfaction, engagement and retention. We set out to understand what affects developer experience through semi-structured interviews with 21 developers from industry, which we transcribed and iteratively coded. Our findings elucidate factors that affect developer experience and characteristics that influence their respective importance to individual developers. We also identify strategies employed by individuals and teams to improve developer experience and the barriers that stand in their way. Lastly, we describe the coping mechanisms of developers when developer experience cannot be sufficiently improved. Our findings result in the DX Framework, an actionable conceptual framework for understanding and improving developer experience. The DX Framework provides a go-to reference for organizations that want to enable more productive and effective work environments for their developers.

1 INTRODUCTION

The paper addresses a gap in actionable understanding of developer experience: prior work identifies its dimensions but not which factors matter, why, or how to address barriers. It develops an empirical DX Framework to guide understanding and improvement.

1 INTRODUCTION

  • Improving developer happiness and satisfaction may raise productivity and improve worker retention.The paper cites prior research for these potential benefits.Source: §1 · p. 1
  • Prior work leaves open which actionable factors affect developer experience, why some matter more, and how to overcome barriers.Some factors may be easier to act on than others, such as project directional clarity compared with personality style.Source: §1 · p. 1
  • The study builds on prior research to develop an empirical conceptual framework for understanding and guiding developer experience improvements.The authors conducted interviews to identify factors, why developers value them, and how they may be acted on at individual, team, and organizational levels.Source: §1 · p. 1
  • The DX Framework identifies actionable factors, contextual influences on their importance, barriers to improvement, and strategies and coping mechanisms developers use.It is grounded in interviews and intended to guide developer experience improvements.Source: §1 · p. 1

2 BACKGROUND

The background frames developer experience as multidimensional and personal, then positions the study as examining actionable factors across experience-related constructs. It focuses on what matters, why, and what can be acted on.

2.1 Defining Developer Experience

  • Developer experience is defined as how developers think about, feel about, and value their work, spanning cognition, affect, and conation.The dimensions concern beliefs and evaluation, emotions, and expectations, motivation, and perceived value of work behaviours; they interact and shape future intentions and actions.Source: §2.1 · p. 2
  • Personal traits and external social forces shape the dimensions, and factors influencing one dimension typically also influence others.External forces include the nature of work, the work environment, and whether developers work in a team or collective.Source: §2.1 · p. 2

2.2 Factors That Impact Developer Experience

  • Prior research has examined happiness, satisfaction, productivity, and motivation, but this study considers developer experience overall to identify important and actionable factors.The authors emphasize why factors matter and which may be actionable, rather than focusing on only one or two constructs.Source: §2.2 · pp. 2–3

3 METHODOLOGY

The study uses semi-structured interviews and iterative qualitative coding to investigate developer experience factors and improvement. The analysis yields the framework’s core categories and an unexpected finding about how experience dimensions relate.

3.2 Semi-Structured Interviews

  • The study used semi-structured interviews with 21 developers to explore factors affecting developer experience and how teams improve it.Interviews lasted 45–90 minutes and were recorded and transcribed; the researcher watched the original video during coding.Source: §3.2 · p. 3
  • Interviews elicited participants’ own factors before using literature-derived prompts to discuss importance and actionability, then explored their ability to improve experience.Interview questions were adjusted to participants’ circumstances; the prompt list was used to deepen discussion and surface less salient factors.Source: §3.2 · p. 3

3.2.1 Interview Participants

  • Participants were recruited through convenience sampling and had over six months of professional experience; only one woman agreed to participate.Participants came from multiple countries and regions in America and Europe and varied in experience, industry, and organization size.Source: §3.2.1 · pp. 3–4

3.3 Coding Process and Developer Experience

  • The authors used open, inductive coding and iterative review, stopping recruitment after three consecutive interviews produced no new codes or insights.Two or more authors conducted and coded interviews across iterative cycles.Source: §3.3 · p. 4
  • The researchers divided transcripts into units, developed focused codes, grouped them through axial coding, and used visual mapping, discussion, and memos.The coding produced categories and core categories, which aggregate categories in the code hierarchy.Source: §3.3 · p. 4
  • Five core categories from the analysis became framework components: experience factors, contextual characteristics, barriers, improvement strategies, and coping mechanisms.These categories were identified early in the analysis and formed the study’s main research outcome.Source: §3.3 · p. 4
  • The researchers did not align emergent factors with the trilogy of mind; codebase health affected thinking, feeling, and motivation.They note that cognition, emotion, and motivation are inextricably related.Source: §3.3 · p. 5

4 THE DX FRAMEWORK

The DX Framework places developer experience at its center and organizes the study’s findings around understanding and improving it. Its left side addresses factors and context; its right side addresses barriers and responses.

4 THE DX FRAMEWORK

  • The framework centers Developer Experience, characterized by cognition, affect, and conation; its other components emerged from the study.The central concept was inspired by prior research, while the framework’s left and right sides emerged from the authors’ research.Source: §4 · p. 5
  • The framework’s left side covers factors developers said affected their experience and contextual characteristics that moderate factor importance.The factors came from the first, unprompted part of the interviews.Source: §4 · p. 5
  • The right side covers barriers to improvement, strategies for improving experience, and coping mechanisms when improvement is not possible.These categories concern improving developer experience.Source: §4 · p. 5

5 UNDERSTANDING DEVELOPER EXPERIENCE

The findings group factors affecting developer experience into development and release, product management, collaboration and culture, and developer flow and fulfillment. They also show that factor importance varies with context, expectations, and individual circumstances.

5.1 Factors Affecting Developer Experience (DX Factors)

  • The factors were identified from interview responses before literature prompts, and each emerged for at least two participants; the authors did not count their frequency.The authors note that their factor categories reflect their own experience and knowledge, and that other categorizations are possible.Source: §5.1 · p. 5

5.1.1 Development and release

  • Development and release factors include codebase health, development tools and infrastructure, automated testing, and frictionless releases.Participants linked difficult-to-understand code and slow feedback loops to poorer experience, while testing builds confidence and smoother releases support small, incremental changes.Source: §5.1.1 · p. 5

5.1.2 Product management

  • Product-management factors include clear goals and manageable tasks, reasonable timelines and developer input on priorities, business impact, and avoiding discarded work.Participants described unclear or large tasks as requiring effort to clarify and break down, tight deadlines as stressful, and changing product direction as a source of thrown-away effort.Source: §5.1.2 · p. 6

5.1.3 Collaboration and culture

  • Collaboration and culture factors include peer support and knowledge sharing, constructive code review, cross-department collaboration, communication, recognition, aligned values, and psychological safety.Support matters especially to junior and new team members, while experienced developers also rely on connectedness and shared knowledge; overly critical reviews can harm experience.Source: §5.1.3 · pp. 6–8

5.1.4 Developer flow and fulfillment

  • Developer flow and fulfillment involve bounded autonomy and appropriately challenging work, as well as progress, uninterrupted time, work-life balance, learning, job stability, and career growth.Participants valued work that is neither boring nor overwhelming and autonomy with clear limits for safe experimentation.Source: §5.1.4 · p. 8

5.2 Factor Importance

  • Psychological safety was often treated as paramount, while negative, unexpected, or normalized problems influenced how strongly other factors mattered.Participants said a supportive culture encourages developers to raise and tackle problems; they also described problems as outweighing positive factors, with expectations shaping what bothers them.Source: §5.2 · pp. 8–9
  • Company goals, organizational maturity, and problem frequency shape which DX factors developers consider important, alongside personal and project circumstances.For example, release factors matter more when frequent releases are a company goal; participants also related importance to seniority and personal interest.Source: §5.2 · pp. 8–9

6 IMPROVING DEVELOPER EXPERIENCE

The section maps organizational and technical barriers to improving developer experience, strategies used by individuals and teams, and coping mechanisms when friction persists. Barriers are often interconnected, while improvement efforts can be constrained by organizational priorities and limited influence.

6.1 Barriers to Improving Developer Experience

  • Barriers are primarily organizational, often interconnected, and include low prioritization, scarce resources, unclear processes, limited ownership, weak incentives, politics, and difficulty finding viable solutions.Problems can compound: lack of ownership may leave developers silent, reducing organizational awareness and further inhibiting improvement.Source: §6.1 · pp. 9–10
  • Efforts also stall when problems are hard to quantify or make visible, stakeholders lack buy-in, or developers do not feel expected or empowered to improve things.Participants described status-quo acceptance and difficulty gauging whether colleagues shared their concerns.Source: §6.1 · pp. 9–10

6.2.1 Individual Strategies

  • Individual strategies include pragmatic tradeoffs, job crafting, risk-taking, speaking up, local fixes, workarounds, and learning how to navigate change by mimicking others.Developers described extending their responsibilities to improve systems, making local collaborations when broader change was out of reach, and working on multiple tickets to accommodate slow reviews and tests.Source: §6.2.1 · pp. 10–11

6.2.2 Team Strategies

  • Team strategies include building cross-team relationships, creating transparency, convincing stakeholders, and breaking large problems into incremental changes.Shared visibility can support buy-in, while smaller units make complex improvements more manageable.Source: §6.2.2 · p. 11
  • Teams can use metrics to make problems and progress visible, learn from improvement efforts, appoint a respected driver, and involve experts when skills are lacking.A driver is described as having relevant strengths and connections to influence people whose buy-in is needed.Source: §6.2.2 · p. 11

6.3 Coping Mechanisms

  • When improvements remain out of reach, developers may seek gratification in personal projects or reassurance by validating shared negative experiences with peers.Participants said side projects could help counter imposter syndrome, while peer acknowledgment could feel reassuring even when problems remained unchanged.Source: §6.3 · pp. 11–12
  • Other coping responses include working overtime, ceasing to speak up, reducing engagement, and gaming the system through inflated time estimates.Some participants described improvement work outside normal hours; others said they limited effort to required duties or managed expectations to make time for improvements.Source: §6.3 · p. 12
  • Leaving a job was described by nearly every participant as a last-resort response to poor developer experience that did not change.One participant said workplace friction contributed to unhappiness and was part of the reason for leaving.Source: §6.3 · p. 12

7 DISCUSSION

The discussion presents the DX Framework as a holistic, empirically grounded way to organize factors, context, barriers, strategies, and coping mechanisms. It proposes using the framework to guide research and practitioner action, while noting that the interviews do not establish causal relationships among its constructs.

7.1 Implications for Researchers

  • The DX Framework combines developer-experience factors, contextual influences on their importance, barriers, improvement strategies, and coping mechanisms.The discussion says culture and work context matter especially, and that seniority and problem frequency can shape experience.Source: §7.1 · p. 12
  • The framework can frame propositions about interventions, but the study cannot claim correlations or causal relationships among its constructs.The authors call for future work to expand the framework, build theories of improvement, and develop measurement models for its factors.Source: §7.1 · p. 12

7.2 Key Takeaways for Industry Practitioners

  • Interview findings associate developer experience with productivity, engagement, satisfaction, and the likelihood of staying in a job; all interviewed developers reported at least one recent negative factor.The discussion says leaders can surface improvement opportunities by inviting teams to share and discuss pain points.Source: §7.2 · p. 13
  • Factor importance varies with role, activities, and goals, while nearly all interviewees described psychological safety as critical to sharing problems and working toward improvements.The discussion also identifies organizational and technical barriers to improvement.Source: §7.2 · p. 13
  • The proposed Ask-Plan-Act process recommends eliciting individual experiences, assigning owners and resources to improvements, then making continuous small changes with fast feedback.The authors describe the process as based on interview findings, research-team expertise, and practitioner discussions.Source: §7.2 · p. 13

8 THREATS TO CREDIBILITY AND RELIAIBILITY

The study describes credibility risks and the steps taken to address them, while noting that interview prompts and the factor list may have influenced participant responses. The authors report reaching saturation among a relatively homogeneous group of 21 active software developers.

8 THREATS TO CREDIBILITY AND RELIAIBILITY

  • Researchers checked automatically transcribed interviews against video, correcting errors and replaying segments to better understand participants’ statements.The authors characterize this as helping them understand context and content as much as possible.Source: §8 · pp. 13–14
  • To reduce interpretive-validity risk, researchers paraphrased key statements, asked clarifying questions, collaboratively established categories, and documented coding in an audit trail.The audit trail included recorded videos and complete transcripts.Source: §8 · p. 14
  • The authors report saturation after no new categories or concepts emerged in the last three interviews with 21 relatively homogeneous active software developers.They note that this sample size exceeds Guest et al.’s recommendation for achieving saturation.Source: §8 · p. 14
  • The interview framing and factor list may have biased responses, so the authors used follow-up questions and distilled DX factors only from discussion before showing the list.They also asked participants to describe their experiences and share details.Source: §8 · p. 14

9 CONCLUSION

The conclusion presents the DX Framework as an actionable account of factors affecting developer experience and of how their importance depends on context. It also offers a concise definition: “Being empowered to do my best work, joyfully.”

9 CONCLUSION

  • The DX Framework identifies factors affecting developer experience and how their importance depends on developers’ contextual characteristics.The conclusion also reports barriers to improvement, strategies for overcoming them, and coping mechanisms when experience is not sufficiently improved.Source: §9 · p. 14
  • The authors state that improving developer experience can improve productivity, satisfaction, retention, and organizational performance.Source: §9 · p. 14
  • The proposed definition of developer experience is “Being empowered to do my best work, joyfully.”Source: §9 · p. 14
Loading 2205.06352v1…