However, this is illustrating a particular problem that only[2] affects engineers -- engineers are the ones at the end of the day who have to make a solution reality.
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).
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.
The topic of the video isn't that everyone else is an idiot, it's that they are not deferring to the person they themselves acknowledge to be the expert to provide expert insight, perspective, knowledge, and requirements gathering. The expert says "you can't have seven lines that are all perpendicular to each other", those outlining the requirements challenge the expert on that, as if the expert is lying or making the service provider look bad by saying something is impossible. "You're the expert, figure it out". "Are you saying that, as an expert, you can't do this?". "Ignore geometry". Trying to get to the bottom of what the requirements actually are (which is often, in my experience, a misapplication, misunderstanding, or misdefinition of terms) is considered being difficult or not being a team player.
Also in my experience, the problem arises when the engineer is brought in the last and final stages after everyone else has already spent significant time on "the problem", and are married to their unworkable solution. The solution isn't necessarily unworkable because it's actually impossible, but often it's because what's been requested and sold to everyone else (read: upper management) is actually too expensive to implement. This is also where undoable aggressive schedules come from. Make no mistake, just about everyone is bad at estimating time and effort when it comes to software projects (this is well documented, at least in the lore), but if only two weeks of time/money are budgeted for what the engineer thinks is a four week project (even if it's actually an eight week project), no one wants to hear it. And it's easy to blame the person who was last to the party.
Trying to get to the bottom of what the requirements actually are (which is often, in my experience, a misapplication, misunderstanding, or misdefinition of terms) is considered being difficult or not being a team player.
There are usually ways of dealing with this situation without confrontation or hostility though, and the distinction between requirements and solutions is an important one - in this case the client tried to present a solution when they should be stating the problem. I find most clients are happy to rewind and state the problem, and it helps a lot in presenting an alternative solution if you can then say - well this other solution solves your problem (and is not impossible given other constraints!).
I'm not defending the clients in this video, who are made to act as idiots parroting obviously absurd lines, what I'm questioning is whether this is even a caricature of reality. I think it's more an accurate representation of the world view that some people retreat to when faced with difficult clients who don't understand solutions and want impossible things (and we've all met them).
Sure there are political considerations and sometimes companies are completely dysfunctional - in that case it's best to fire the client or job and move on, but it's very rare in my experience as a developer or designer to come across that. If you can't do your job in a given setup, and can't push back, the best option is to leave, because you can't fix that and it is an unhealthy situation for all parties.
It's possible to respect that the other people in the meeting are experts in their own topic and still find the level of misunderstanding hilarious. I work with a team of biologists and I know we all feel like that engineer during meetings.
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).