What it is like being the only engineer in a meeting [video]

That's not true. Almost every role is a specialty, and almost every role requires translating requirements from others who do not understand the solution space into solutions which meet that requirement, and explaining just what is possible and what is not. Just as one example, designers translate things like 'I need this text to read better' to adjusting the leading, measure, weight, size and font to something appropriate while meeting the other existing constraints. You could think of examples like that for almost every specialty, including designers, business people and accountants, who do things the developers don't understand (but might think must be trivial, because they don't understand them) which are just as vital for the company. There are also plenty of examples outside the fields developers interact with (engineers, architects, doctors, lawyers etc).

The meeting in the video wasn't funny as a caricature because it portrays everyone around the developer as idiots, though I suppose it is a brilliant unintentional caricature of the way an ignorant specialist might see the world. In real life, the clients are not idiots, they just have conflicting requirements, and don't understand the solution space, but they usually understand the problem space better than the developer and should be seen as a mine of information and gently guided away from making decisions they don't understand. A developer (or any other specialty) seeing the world this way is a bad developer IMO, and someone facing something approaching this situation in real life should just get another job, as clearly working for idiots is a losing proposition.

Back in real life, both design and development require very similar skills - refining requirements, proposing solutions which will work, persuading clients as to the best solutions, taking on board their ideas and adjustments gracefully without compromising the technical constraints. The issue of dealing with clients who don't know exactly what they want or what is possible is probably similar in a lot of other domains, and the laziest solution is to call them idiots and dismiss their concerns.

What I'd do in this situation is ask the client to rewind and state the problem (our lines clash and we can't change the colour or make them see-through), not a proposed solution (7 perpendicular red lines, one of which is green and transparent).

At least, I hope there aren't real-life Certified Red Line Experts running around, nor designers hoping to draw red lines in green ink…

Taken too literally, this sketch could be offensive to all of women, portrayed as clueless; male executives, portrayed as willfully ignorant and over-demanding; Asians, portrayed as obviously engineers; non-Asians, portrayed as obviously not engineers; engineers, portrayed as incapable of working backwards from impossible requirements to find a solution that actually works; and probably other groups I've forgotten.

It's that when it comes down to actually making it work, it's the engineer that has to provide a working solution to the specification. Not a figurative engineer with years of experience and knowledge. The actual person that has the task. Pretty much everyone else in the chain has to make assumptions about what is possible, in what time frame, with what resources. Yes, the more experience you have, the better you get at doing that.

But trust me when I say that all too often, even product engineers for million dollar figure products, have little idea if X is possibly in time Y until they actually try and do it. (I've worked at multiple companies with multi-million product licenses, and seen it at all of them). Sure, a few of the delivery engineers had a much better idea. But there was no way any of the analysts, project managers, and especially not the sales engineers, had any clue about the time. You'd get answers from 1/10th Y through to 10 x Y - 10000% variance.