An Attempt at Outlining the Many Factors Influencing Developer Experience

Published on September 6, 2022 (↻ October 14, 2024), filed under Development (RSS feed for all categories).

When looking at DX naively, it can seem that it depends on only one factor. Alex Russell recently pointed at this problem when ranting about improving the developer experience of the JavaScript ecosystem by “retiring this language.” But here and elsewhere, is DX only DX(x) (really: DX = ƒ(x))?

No, it’s not. Of course it’s not. Developer experience—Developer Experience—depends on many factors. Here’s a quick attempt at sketching just what factors, each of which can tip the scale. I’m breaking these down into extrinsic and intrinsic factors, because it seems indefensible to assert that an experience only depended on external circumstances. The experience of someone who’s highly motivated is different from someone who’s sliding off the chair.

I’m using the term “product” to denote what the developer would make an experience with. This can indeed be a product, like a tool or service an engineer would use or implement, but also a specification or even a language.

Extrinsic Factors

[I’ve reworked this section, playing with the rough general areas of (technical) quality, usability, and community. Please share your thoughts!]

• Context—the general product ecosystem with its use cases, languages, software, and people

Quality

• Standardization—processes around and reliability of the underlying technical standards
• Language(s)—the programming, document, or formatting languages used and their syntaxes
• Code quality—the objective and subjective elegance of the public-facing technical portion of the product in general, and of examples specifically
• Maintenance—continuous improvements in and around the product ecosystem

Usability

• General usability—a realistic chance to actually use what needs to be used
• User experience—the experience provided to users of the product and its ecosystem (overlaps with the developer experience)
• Documentation—any records of how to work with the product
• Tutorials and guides—hand-holding to start and keep working with the product
• Content quality—completeness, correctness, grammar
• Formatting—readability and consistency of production, research, and sample code
• Aesthetics—an appealing-enough presentation (of key documentation and tooling)
• Sample projects—ready-to-use examples
• Tooling—primary or secondary (supporting) software to work with the product
• Automation—special tools and scripts to assist or supersede certain tasks
• Integrations—software that allows to work with the product in other software (like IDE support)
• Self-service functionality—the ability to use the product without help or intervention

Community

• Communication—reliable, respectful, and constructive messaging from product and tooling providers as well as the community
• Support—peers and organizations actively interacting with and helping each other
• Developer Relations—dedicated developer outreach
• Marketing—knowledge that the product exists, and desire to use it
• Peer group—sufficient acceptance (or lack of detractors) within the peer group
• Organizational pressures—the organization asking to use the product
• Organizational (and engineering) culture—the developer’s professional environment, including corporate expectations, team health, work/life balance, &c.
• Market pressures—the market asking to use the product
• Privacy—few to no user or usage data being collected, let alone sold

Intrinsic Factors

• Knowledge and experience—empirical or previous conceptual exposure to the product
• Motivation—eager to learn, or forced to do “a job”
• Resilience—can deal with obstacles, or gives up easily
• Philosophy—like pragmatic, ambitious, or quality-oriented

❧ Recall the theory: Any of these factors changes the developer experience.

And recall the premise: This is a quick shot at DX factors, to fend off the idea we can fix it by changing one single thing. We can’t—most likely, we need to fix more factors. And then it may still be broken by another. Developer Experience needs to be approached holistically—for it’s much more complex than just DX = ƒ(x).

Many thanks to Thomas Steiner and Francesco Sciuti for reviewing and sharing feedback on this post.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)