Hacker News new | ask | show | jobs
by imbnwa 1731 days ago
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.

2 comments

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.