|
|
|
|
|
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. |
|
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.