An Attempt at Outlining the Many Factors Influencing Developer Experience
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.
- Context—the general product ecosystem with its use cases, languages, software, and people
- 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
- 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
- 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
- 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—we probably 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).
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe this is interesting to you, too:
- Next: 0 of the Global Top 100 Websites Use Valid HTML (in 2022)
- Previous: 11 Tips to Read More and Read Faster (After Reading 791 Books in 9 Years)
- More under Web Development, or from 2022
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.