I don't think this analogy is useful. I think understanding the why is important. The plumber knows why you want running water, has seen many homes with water s

I don't think this analogy is useful. I think understanding the why is important. The plumber knows why you want running water, has seen many homes with water systems similar to yours, and almost certainly owns a home himself. But introducing software into someone else's business has no such guarantee of familiarity. There has to be a discovery process, where you choose between several ways to fulfill the need, with a much larger problem space than home water systems. In my experience, a large part of software is automating processes, and I can't imagine replacing a process properly without understanding why it is done in the first place. Business owners can understand a problem at a high enough level to hire people to solve it, but software engineers in that position have to understand a problem so well that they can describe it to machines who will take every step at face value, executing it unthinkingly. Encoding a bit of the why something is being done, even if it's just in manual tests of the software, has been crucial for that software to do the job properly in my (limited) experience. I'm not being jerked-around being told to make sandwiches. I'm being told, the water-operated sandwich making machine is too slow/doesnt work properly. I might just as easily recommend a sandwich catering service, or pick up a manual on building fancy electric sandwich makers, as repair/enhance the water pipes. Disclaimer: I'm a young software engineer who, perhaps naively thinks I will always be able to join interesting projects and learn new things while being treated like a partner instead of a technician. This has been my experience so far, but perhaps you reach a point where, having specialized, you churn out the same solution for company after company in a niche for efficiency reasons.