The Case for ‘Developer Experience’
Developer experience, or DX, is usually defined as the sum total of how developers interact with their tools, day in and day out. Yet as an essay from Jean Yang points out, a large part of that experience still gets ignored, despite the growing number of talks and panels on the subject.
Because developers spend less than a third of their time actually writing code, DX also covers maintaining code, testing, security issues, and dealing with incidents. These aspects tend to get overlooked because they are messy and complex, with no simple “silver bullet” fix.
Yang argues that DX has been oversimplified, and that tools actually fall into two distinct categories with different needs:
- Abstraction tools, which assume we code in a vacuum.
- Complexity-exploring tools, which assume we work in messy, real-world environments.
Most developer experience work so far has targeted the abstraction category, where best practices are easier to pin down. The other side, complexity-exploring tools, has largely been left unaddressed.
As Shawn Wang puts it, the field needs to go beyond the easy questions in developer experience and start confronting the uncomfortable ones.
