Interesting, a previous company I worked at (Triply) highly focused on DX as well. But their characterisation of DX meant that the employees of that company were having an amazing developer experience.
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 ;-)
> If you can't even choose the OS you want to work with
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).
Yeah, I care about the code that comes into the repository: charset, tab/spaces, style, etc. Who cares about the OS or IDE the developer used to commit or type? Unless you see a productivity/code issues problem...
There is a productivity problem with supporting multiple OSes: either one OS is unsupported (and people who use it waste their time configuring it), or all the tooling, internal documentation and tutorials has to support both - in which case it is often almost double the work.
I have personally seen team members waste days of their time because they tried to adopt an internal script to MacOS, instead of just using Linux VM as recommended.
i'd say a standardized OS and environment for onboarding is a better experience for onboarding so everyone is on the same page. doesn't mean you can't change it to something you prefer though.
I think the embedded tweets by Malte Ube basically clears up this whole thing, author appears to be confusing roles with outcomes, like, yes, developers could be your users... and? Am I missing something more? There's still a difference between the developers who develop your product and the developers that use it (dogfooding applies to a small segment of products, not enough to jsutify the generality of this post title though, no?).
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.
This post is more oriented to those building developer tools, APIs and platforms. You have to understand developers from a needs/value perspective in relation to the product you are building, and sometimes “developers” need to be described as multiple personas; the developer at your customer who is extending your product is different than the ISV/3rd party building for your marketplace. There are usually tensions in the dynamics of the product between developers and other user personas in terms of their needs, tolerance to complexity, motivation and desired outcomes.
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.
Until of course there's an ask to turn that simple website into a complex one that supports multiple flows, handle various user interactions, and begin pulling data from various sources.
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.
> The web browser product is a loss leader and the team's relationship to developers and users is not altruistic; it’s complicated!
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!
It’s definitely happening and from multiple vectors including productivity, privacy and decentralization. Now that Chromium powers every major browser (except Firefox), it’s helped stabilize a standard base for others to disrupt upon like:
This article makes me wonder where the insight of Alan Cooper in "The Inmates Are Running the Asylum" has gone to. As a matter of fact, the priorities and pressues of the corporate software engineer are often in conflict with the vision of product leaders who would like to take a more holistic, big-picture approach to the total user experience. (FWIW, I am a software engineer)
DX is the experience of the people who build the product. If the users happen to be developers, it’s still UX.
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.
I don't think seeing developers as users is interesting but I definitely think that DX impacts yourself users experience. So in that sense your DX is your UX.
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).
I have personally seen team members waste days of their time because they tried to adopt an internal script to MacOS, instead of just using Linux VM as recommended.
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.