There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course):

- The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements.

- The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear.

In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.

In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.

In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.

> I would think the engineers usually get their kick out of making things fast or easy to maintain

Is your company hiring? Because I've spent 30 years being this engineer and nearly everyone looks at me like I've got horns growing out of my head.

That's not where most engineers find their job satisfaction, more's the pity. And they think they know better than users. There's a reason UX has been around for at least four decades longer than DX. Developers think both are made up.

> If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor?

Playing along with this analogy, what I think we see a lot of in product development is the customer going to the PM and saying they need the cone to have a cover. The PM and the customer iterate over the specifics of the cover. PM goes to the engineer and tells them the cone needs a cover that meets x, y, and z requirements. Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.

And thus the tub was conceived. By someone who was watching people wrangling with cones.

> I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for.

Isn't that the point? In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head. In the open source world it's more reasonable and common to design a tool not predicated on the predominant models and workflows. And every once in a awhile those experiments result in something very valuable that helps to break predominant paradigms. But in the commercial space solving customer's immediate problems in a manner that is intuitive for them is paramount.

I have long believed that the biggest issue here is that engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX. They are not always the best people to judge how or if less experienced users will tolerate or adapt to those patterns. It’s fine to have opinions but they must be prepared for them to be challenged. Even better if they can invite others to challenge them, which is essentially what talking to your users achieves.

But is it an informed opinion?

Every human has an opinion on practically everything. But has that human put in the effort to justify pushing that specific opinion?

In this case, is the opinionated engineer humble enough to realize that using software in their day to day life does not equal using software in our customer's context?

Isn't that the same as UI/UX people being generally clueless about how to build applications for the very platform for which they are designing? Designers and product managers constantly have to be guided about the logical and the structural constraints of their target platforms, to be given workarounds, to be taught how to logically divide their reusable components so that they can build their dream design system which, by the way, always fights the platform's native design system.

It's totally fine to have an opinion on UI/UX if it is informed by cognitive psychology and other relevant HCI subfields, in the same way that it's OK for UI/UX to push for designs so long as they are also informed by business and engineering.

That’s the attitude he’s talking about!

I think you're right. Similar to the article's title, a useful thing is dogfooding. But where this can go wrong is because conversation is engineer to engineer (not exclusively) is that the takeaway can be "Oh, I was holding it wrong" instead of "this was not as intuitive as I thought, how can I fix that?" I know there's backend vs frontend arguments[0] but I think backend needs to be conscious about front end. When we write backend it is easy to just focus on making things work but we're a few steps back from typical (or targeted) use cases.

Classic problem with us eningeering types, right? When you're in the weeds it is easy to see the differences. Humans are always biased to forget how difficult it was to learn something, judging on level of current (subjective) difficulty. For me a big change in framing came through Linux. I'd convince my friends to use it and then as the years went by I saw how much easier it became to do so. Now, for the most part it is much easier for an average person to use. There difference isn't "holding it wrong" so much as "it's hard to hold" (or "it's hard/unintuitive to hold correctly"). Even just with the more recent rise of TUIs. Even us terminally terminal types are loving the new TUIs and ultimately that is a frontend thing. It's just frontend for backenders, allowing us to stay in the environments we are efficient in, maintain our power and flexibility, but also get some aesthetics (which has functional utility! I bet you use syntax highlighting, and not just because it is pretty).

There's a strategy to writing backends that I think helps both backend and frontend: write flexible code. It draws from the unix philosophy, where functions (or small programs) should be containerized or focused. Then the complexity happens by putting the things together (there's a hierarchy to this). Helps write backend code so it is easier to maintain, reduces repetition, allows for quicker feature development, and ultimately makes it far easier to read. It's a little more work up front, but it sure pays dividends. It helps front end people because ultimately they are towards the... *front end* of that hierarchy. Makes it easier for them to pull pieces together, wrap things, and communicate with backend types.

Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. Why is there always time to do things twice but never enough time to do things right? It all depends if we're running a sprint or a marathon. A sprint is all about speed, but a marathon requires a lot of strategizing. A marathon requires some sprinting, but you can't sprint the entire thing. We like to drop sayings like "don't let perfection be the enemy of good" but truth is it's not about perfection, it is about different ideas of what is "good enough." Which, is ultimately an issue of communication.

[0] I'll still argue backend is more important ;) because that's the foundation. Your building can't stand, let alone be pretty, if it doesn't have a solid foundation and skeleton. All that is invisible though. Maybe that's why these arguments occur.

Don't try to tell them that.