If you are designing or writing software for someone other than yourself, you’ll spend some about of time wanting to roll your eyes at people thinking they know how to do your job. Non-technical product managers will suggest specific technical solutions that they’ve heard of but don’t clearly understand. (MongoDB seems to turn up a lot in this context, for no reason I can discern.) Salespeople with no special background in UX design will prescribe inappropriate or outdated UI idioms. (Hamburger menus, a.k.a. pancake menus, still retain a lot of mindshare.)
Your natural and completely appropriate reaction to this sort of thing might be to want to start hitting people with a shovel, but this is bad for repeat business, and not legal in some places.
The thing you have to remember is that these nice people hired or contracted you (or your employer) because they don’t know how to do what you do, even if they sometimes forget this during requirements definition. You’re the expert. When a client falls into buzzword glossolalia, thinking he’s offering a valid technical solution, a better approach is to holster your shovel and say something like: “Let’s not get bogged down in technical details this early. Why don’t we take a step back, and you tell me what you want to accomplish by doing that, and then I can do a proper assessment of whether X is the right tool for the job.”
Gently draw the non-technical client’s attention away from the technical questions best left to you; bring your focus and theirs to the business problem they want to solve, and about which you may reasonably hope they know something. I’ve yet to have a client object to me caring about their problems and wanting to choose the best way to solve them. (Of course, then you’re on the hook to actually solve them, but that’s a topic for another post.)
There is, of course, a flip side to this, but I’ll write about that tomorrow.