What did that look like?
* Dell XPS with Linux, you also know that everyone else has a Dell XPS and Linux
* An onboarding document to set everything up and it just worked
* Strong focus on using a good IDE/text editor for their TypeScript codebase
* Strong focus on writing TypeScript in such a way that type checking almost always worked
* Well thought out written issues that were self-contained, yet short and to the point
IMO there were a few improvements they could make but you could tell they cared about the developer experience for any programmer working there.
Oh, and if this sounds standard to you / obvious, well, I got news for you. Most companies don't do these type of things ;-)
I mean not really. Linux is usually an excellent choice for development and if the rest of the company can use it there's probably no reason you can't other than maybe aesthetic ones. IMO they shouldn't take priority over creating a standard dev environment (you still need all OSes for testing, etc but that's a different point).
What most people mean when they talk about the tension between DX and UX are things like people using React everywhere for its intuitive interface and composition even if the project is just a few screens with some text and two buttons at maximum per screen (I work somewhere where there is a product that does exactly this); the JS payload is bigger than the set of possibilities for interacting with the page is. More appropriate would be something ike a DAW in the browser: the set of possibile outcomes, i.e. musical compositions, is big enough to justify the JS payload size.
But talking about interactions/payload size is just one axis of tension, and even in the case above you can reverse it and developers could be using some in-house framework they all like a lot and are familiar with but that imposes unintuitive constrictions on the in-browser DAW they're building in the way of minimizing bugs perhaps, or how fast the screen is updated, say.
In addition the point is also to be careful with generalizations like “What most people mean when they talk about the tension between DX and UX…” I generally agree with Malte but not in every circumstance. If you are a developer that primarily is the consumer of dev tools others produce, it’s common that you’ll only see things from that perspective, but the dynamics are more complex.
A lot of the reason I think people reach for React is because they know there's a high chance of an ask to incorporate more and more capabilities.
This sums up exactly what has happened to the Web over the past decade or so. It got worse because of the design priorities of advertisers competing with the best interests of end-users.
If we're all collectively aware that things have gotten so... ambiguous, doesn't that mean that web browsers are ripe for disruption?
The IP/TCP stack is the real miracle of the internet, everything else is DX/UX layers on top. Creative destruction in this space is totally possible and the worsening experiences of both users and developers make it an increasingly likely possibility too. Vive la révolution!
* [The Browser Company](https://thebrowser.company/)
* [Sidekick](https://www.meetsidekick.com/)
* [Bonsai](https://bonsaibrowser.com/)
New rendering engines in WASM and decentralized communication protocols are potentials for anchoring new alternatives.
1) The eventual end-user of the product (usually, non-technical).
2) The developers that need to maintain and extend the work I do (often, Yours Truly).
It's important for me to keep them separate. Totally different priorities and workflows.
But it is equally important for me to treat them as high priorities.
I get why there is a debate: DX and UX can come into conflict if technology choices don’t serve user needs.
You can optimise your users’ experience by first understanding their needs and then exploring how technology can meet them.
Most of the time, there is no conflict but sometimes tech choices eg buying off-the-shelf software or using a package that isn’t accessible can fail to meet user needs.
