One of my mental models for how people interact with software is shaped by a few plumbing adventures I’ve had. They’re the standard sort of mishaps: one backed up sewer pipe and one overflowing shower drain. In each, I eventually learned the proximal cause (previous inhabitants of house were flushing inappropriate materials; apartment building didn’t have large enough pipes in the shower stack, which meant that our first-floor apartment served as a de facto drain pipe), but I had neither control, nor really any interest in why things were going wrong.
I’m interested in plumbing in an abstract sense. Large-scale human engineering is cool and plumbing history has undergone some interesting turns and twists. The plumbing I live with, however, should just work. I don’t want to think too much about how it works or why it works. I just want to take my shower and get on with my day. I don’t know much about the features that are necessary for that to “just work” — I won’t be able to tell you how wide to make the sewer pipes or how to keep metals from leaching into the clean water. I don’t care much about the features, either. What I care about are a) toilet works, b) shower works, c) faucets work, d) dishwasher works, and e) all the waste water goes away.
A lot of software teams would consider me a really annoying customer. Plumbers don’t, or if they do, they hide it well. They understand that the subject they’ve spent 40 hours a week on for the last two decades is not that interesting to me, their customer, and they tailor their message accordingly. I try to remind myself of this before I push data structures and installer dependencies on software customers — some people just don’t care about anything beyond “Your toilet was clogged. I’ve fixed it. Don’t flush menstrual products. That’ll be $119.95.” And that’s fine. I don’t want to trace pipes in my basement either.