Engineering-glish: The act of speaking to end-users as if they were engineers.
I have a new analogy that I’m using with software engineers. Every time I hear “why would someone do that?” or “They should know not to do that…” my response is now, “How many of you drive over a bridge on your commute?” Since we’re in Florida the response rate is about 99%. 
“Somewhere there is a bridge engineer asking why any of you would drive over a bridge like you are.” I usually get a “WTF are you talking about?” look or response. The software engineers are pretty confused and I respond with “That’s the same look our end-users give us when we speak to them like that. Somewhere there’s a bridge engineer asking why there would be so many stationary, overloaded trucks on the bridge, and why someone would be so close to them, the bridge wasn’t designed with that in mind.” There are thousands of calculations dealing with compression, harmonics, wind, temperature, etc., do you as software engineers truly understand the bridge you’re driving on or do you just want to “use it” to get where you’re going? It’s the latter, get where you’re going. That’s the same for end-users – they don’t want to, nor should they have to, consider how the software was built in order to use it. SPAs are a prime example of this. Hitting the back button wipes a large portion of your selections yet it’s not obvious that a site is build as a single page. Software engineers ask “why would anyone do that” and end-users ask “why would anyone build it that way”. It happens all the time where software engineers are trying to explain to end-users why they shouldn’t hit the back button and it’s a prime example of engineering-glish.
