If UX is user experience, the user flows of a product/application and how people generally feel about using/interacting with it.
The DX is the developer experience. It follows a similar idea. How do you feel about using git? What about Visual Studio Code versus neovim? How do you like using Elm? What don't you like about.
Think about all the libraries or frameworks you use. Some of them clearly offer a better experience than others, these are the types of things that affect the DX.
Take documentation for example, a piece of tech (whether it be an IDE, library, or CLT) with proper documentation full of examples, usage, and recipes is extremely nice. I would favor tech that has better documentation over others, documentation is just one part of the DX. Not the only part, but hopefully you can start to see what can increase or decrease the DX.
> The DX is the developer experience. It follows a similar idea. How do you feel about using git?
To me, how I feel about using (working with) git is git's UX.
How I would feel working on git (were I to do so) would be git's DX.
Now, for a project that has git as part of its expected dev tooling, how I feel about using git in that particular context would be part of that particular project's DX.
It's confusing or always needs further distinction if "UX" when discussing client-side application development is talking about developers. "DX" is useful.
OTOH, when I hear about DX of a software product (especially an open source one), my intuitive understanding is that it is experience of developers working on the product, not of developers that happen to be users of the product (which, if they are the normal users of the product, would just be UX.)
it's a full of crap metric due to the fact that the definition wildly varies among developers. While UX can be quantified by actual metrics (retention, number of steps, accessibility points), DX is nothing but a bunch of opinions.
