For 2 larger projects I'm on, I'm both the developer and a user: on a regular basis I use the software myself. And not just for one-off tests. I really use it the way other users use it.

This has provided rather deep and interesting insights in software development for these particular products and in general. Or in OP's lingo: not a lot of potential for insanity at all. Because any new idea immediately gets regarded on 2 fronts: what does it take to implement and what does it really do for the user.

I find that if people don't dogfood their software the software just ends up being shit.

As engineers we need to be a little grumpy. Frustrating with our software provide directions to improve it. If we're not grumpy, we don't know what to fix.

But some of this also comes from top down. Engineers also need the freedom to fix things. They're the experts. Management Also shouldn't interpret that frustration in quality as the engineer being a thorn in their side. It means the engineer cares and is willing to remove the thorns in their side. But I think there's a strong natural tendency in any organization to surround yourself with yes men. They're sneaky, telling you no when you ask them to. Maybe a reason management loves LLMs so much

In my experience, this is the only kind of software that ends up not sucking. If development is not driven by users in a very intimate way -- like being one and the same person -- then you routinely end up with necessary features only half working or splitting essential information across multiple screens or dialogs. Eating your own dog food is essential to rising above that, because only that reality will overwhelm the developers sense of the "proper" way to do things.

I believe it's the major reason that industry specific information systems are universally shitty. The user can't articulate what they need to accomplish and the developer doesn't really understand the purpose or importance of the work. Result is bad functioning or bad interface.

It's why only software like text editors and web browsers gets to be really good. Huge user base. Lots of developers involved.

Git kinda proves that it's not infallible, though.

Dogfooding is useful certainly but it can also be a trap, as someone who is technical and knows how the software works both sides you can fall into the trap of avoiding triggering the exact kind of issues a regular user can walk into.

Your conceptual model of how things work is going to be different to that persons and it is a very hard trap not to fall into.

This is something I've asked repeatedly at my job. Current team builds services for other developers to use, okay, do we also use it so we can go th ough all the same pain points as them? Why not?!

This approach is really worth pointing out and recommending. Not everyone is allowed / encouraged to realize how powerful it is.