DX stands for Developer Experience

Disclaimer: Developer Experience is NOT about work experience, seniority or proficiency level. It's about how Developers perceive the sum of their work conditions (tools, processes, constraints, etc.) & how it impacts their efficiency & productivity. Analogy to UX/CX is definitely in place.

TL;DR - Software developers have some (very specific & varying) work hygiene conditions expectations - these are hard to understand by non-dev outsider, but ignoring them leads to limited productivity, degeneration of engineering culture & nose-diving engagement. Providing conditions for stable, gradual DX improvement is critical for any company that considers software engineers (& their work products) its key success factors.

Pretty much everyone who's up-to-date in modern IT knows what is UX (User Experience) & how does it differ from UI (User Interface). Many dive even deeper - terms like Information Architecture, Interaction Design or User Persona are well recognized & widely applied to build better solutions that bring more value to the end-user.

But far fewer recognize another, similarly sounding term of no negligible importance either - DX (Developer Experience). Hence my goal for today - to describe what DX is & why one should care.

What is DX?

I don't like any of the definitions that can be found on the web, so I'll try to form my own :)

Developer Experience (DX) - the overall sum of all non-domain (non-business) & non-human factors that directly influence developers' daily activities in a way that translates into impact on the process of delivering (speed, quality assurance, etc.) software development work products & products themselves (quality, maintainability, reliability).

Yikes, looks a bit dry. Doesn't it?

In more plain words - it's a quantification of how ergonomic, convenient, reliable & in agreement with engineering common sense development process is. It's about whether i.a.:

devs have all the necessary knowledge & resources (accessible w/o burden or delay)
the tools are fit for a purpose (not clunky, but responsive, error-free, etc.)
work environment puts on dev restrictions that impede their work w/o justification
people feel their are fighting the complexity of the problem, not the stupidity of the system
code being written is addressing the functional requirements, not fulfilling abstract boilerplate concepts (due to poorly design API / syntax / interface)

Obviously this "quantification" isn't very tangible - I'm speaking more about the "feeling" or "attitude" as there is no formula for DX & it can't be expressed in any formal unit ...

What impacts DX?

On practical terms, what are sample "impact vectors" for DX? To simplify things, I'd split them into two categories:

internals - ones related to team's work products (mainly functional code & deployment setup) - how architecture is organized, what is the degree of internal coupling between solution elements, the approximated level of technical debt / tedious task automation / quality & completeness of documentation for the most vital app components - stuff devs can impact directly without a need for external support
externals - ones related to the organization, platform, process (out of team control boundary), provided resources - do they follow (/support) modern software development practices? don't they introduce artificial, impeding cross-competence/team/unit boundaries? do tools force workflows & practices that fit the organization/purpose? - stuff that is determined outside of the team unit & can't be easily adjusted (but maybe can be replaced or abandoned)

Internals are no-brainers - in undocumented, humongous monolith with full spectrum of dated conventions, messy code structure & zero test coverage it requires a lot of resolve, determination & effort to make any change, especially an architecture-impacting one. You never know the regression scope, whole system is brittle, one change can force a small avalanche of subsequent ones (because implementation details have leaked out of presumed bounded context). DX is terrible, because whole system is a pain to touch.

Externals are of a bit different nature - shared database (or any other critical resource); being dependent on another, capability-based team (e.g. ESB team) in day-to-day activities; inefficient tools (like a slow compiler, buggy IDE or dev machine with too little of RAM) or dumb corporate policies (limited Internet access or can't run local web server on your machine). DX is terrible, because under such circumstances you just feel you could do much better/faster, but it's the system that prevents you from doing so.

Why DX REALLY matters

Most painful thing about reduced DX isn't really about reduced productivity (even if this direct outcome is very tangible & easy to understand). Think rather about the human factor - or more precisely people realizing that they are not using the full potential they could use.

In case of internals - team loses faith in their leaders or that it's possible to learn anything useful from them, doesn't identify themselves with the work (/product/service), avoids to take any ownership & as an end-result: decreases their engagement for minimum level.

In case of externals - walls & divisions are being erected ("we VS them"), individuals feel like crippled subjects of processes & workflows they don't understand, work itself tends to be demotivating due to countless activities that don't deliver value, employees build up some kind of "resistance", because they feel that any kind of improvement can happen only bottom-up, if they limit transparency & openness.

In both cases low DX equals increasing annoyance, feeling of being powerless & frustrated. Insufficiently DX-infused work environments are almost completely devoid of innovation, initiative & the positive vibe of creative community. These are not good places to work & employees usually focus on finding the way out. The more they delay the departure, the worse for them.

What DX isn't

Let's make it absolutely clear. DX isn't ...

... about using the most cool platform / tool / library that is getting the most attention on the web - the focus in DX is on both usefulness & usability, not just developer's satisfaction from using the latest shinies. Stability & productivity are absolutely essential here. Pragmatism FTW.
... 100% objective. Devs have different opinions, different preferences & not everything can be assess based on sheer facts only. That's why there should be a clear set of baseline rules that determine how decisions are made once facts give their way to opinions.
... granted forever. Platforms, tool-sets & processes need to evolve to match the advancements in technologies, methods & paradigms of modern day development.
... about do whatever you want / use whatever you prefer. Without alignment & shared vision there will be no synergy, no knowledge sharing, no accelerated growth.
... coming w/o the price. Or rather - the DX improvement always requires some price & in many cases the most eager devs ignore / belittle it. This price isn't only about the immediate effort, but also about the long-term effect: e.g. can you replace old tool completely with the new one? what is the effort to keep old & one in parallel (even temporarily)? can these be used interchangeably?
... superior to delivering business value. Satisfying the needs of consumers is still the main goal & technology (DX included) HAS to adjust to this fact. But on the other hand, while considering this "satisfying" one needs to think long term, keep in mind hidden aspects (like maintainability or resilience) so it's fine & understandable to sacrifice a bit of today's business value to get more DX (& hence improve efficiency) long-term.

DX is all about deltas

Yupp, that should be the key outcome for you from this blog post. You should be looking for workplace with good conditions (high potential) for continuous DX improvement, not necessarily for ones with the highest "absolute value" of DX. Even if current DX is rather low, but there's will, capability to change it & the vision of how to do it, this sounds like great environment for continuous learning, building up good habits, sustained personal development & doing work that brings satisfaction, not frustration.

As I've already written above, DX is not given forever - if high DX work environment degenerates somehow (usually because key people leave or due to some other human-factor), DX withers, decays & falls into fast-pacing entropy.

Stable, gradual DX increase, even mid-term, can make wonders & provide unprecedented satisfaction from the work done. In contrast to what you may be thinking, software workshops that try to go all-out for max DX in (too) short period of time, usually end bad -> postponing the delivery of any business result eradicates trust (of business stakeholders), increases the difficulty of validating introduced improvements (due to mutual impact of changes) & cripples overall stability, causing internal resistance to any change.

How to keep DX high (enough)

There is no & there won't be any generic prescription of how to do that. It's too dependent on work environment specifics: product(s), platform(s), scale, operating model, etc. What I can suggest is only some hints, key questions you should ask yourself, major factors you have to keep in mind when making the decisions that can impact DX:

focus on interruptions - if anything disrupts "the flow" think 5 times whether this (interruption) is intended, necessary, brings any value / has any justification -> this applies both on developer's level (developer's daily routine) & end-to-end delivery level (full delivery cycle)
use hard currency as a metric wherever it's possible - if there's a question of spending money on some software license, try to calculate the exact amount of money it will save you; e.g. code analysis tool may be expensive, but putting it (as a vehicle for convention testing) into your CD pipeline may seriously reduce troubleshooting time
your delivery process HAS to cover processing "technical tasks" (how they are chosen, prioritized, tested, etc.) just like the business ones - they should not be an exception but a standard element of delivery pipeline
each task should have its success criteria, even if it's DX improvement task - otherwise people will be "playing" to much without adequate focus or guidance
versioning strategy(/ies) for all the work products is essential - all the elements in your dev factory should be "changeable" in a controlled manner, without breaking all the upstream / downstream dependencies around; btw. not versioning at all (full backwards compatibility) IS also a strategy (if deliberately chosen)
listen to people, but mind that their perspective may be very "local" - developers indeed do know what slows them down, so they definitely should be the first ones to listen to when considering DX, but they may also be lacking higher-level perspective, or in other words - they may know the answer to question "how", but this answer may be somewhere there & it may be perfectly valid
focus on problems, not solutions - otherwise you'll end up sticking in all the stuff cool kids on the Internet blog about; is it a problem? does this problem affect us here (or is it Google's/Facebook's/Amazon's or other unicorn's problem)? what's the actual level of impact?
re-use industry best practices - each company is a bit different, but delivery processes are usually built on very similar foundations, so don't re-invent a wheel, but start with industry standards, adapt them to your conditions & slowly evolve; if they strongly differ from the ways you were doing stuff until now, first think whether the difference provides you any tangible advantage - if it doesn't, strongly consider simplification & standardization
optimize for the velocity of change - evolve fast, in small chunks & collect feedback frequently; avoid getting vendor-locked & distribute the risk - personally I prefer composition of smaller "best-of-breed" tools / components over one, huge, commercial package - as long as I have a flexible-enough & dependable-enough "glue" to integrate them all
NEVER FUCKING EVER take on large-scale, hard commitments (e.g. big projects) w/o cleaning your shit first; otherwise it will end not in just an exhausting death-march, but also botched (even if finally delivered) end-product & best people leaving you with that crap

One last remark: 10x developer productivity is indeed a myth or rather a misunderstanding. What one may sometimes experience is not really 10:1, but rather about 1:0.1 productivity ratio (with a relative effect being the same, I know). Such a 0.1x productivity is very real - with a crawling DX being one of its key reasons.

Beware or it will become your standard.

P.S. If you like this post and find its content useful & relevant, please don't hesitate sharing it with ones who may (according to you) benefit of it as well. Thanks in advance.