
This is how an engineer feels when he's surrounded by idiots - jtoeman
http://www.cnet.com/news/this-is-how-an-engineer-feels-when-hes-surrounded-by-idiots/
======
abbasmehdi
I have been in a lot of meetings where business-types suggest all sorts of
ideas. I used to get really frustrated and would take the easy way out, i.e.
think to myself that these guys are clueless, why am I even in this business,
and just go in a really shitty place mentally.

Then something changed. About the tens of sales books I read, a nugget from
one of them struck me. The idea was to re-focus / re-frame any conversation to
"what are the business objectives we are trying to achieve here?". Instead of
having them propose solutions, have them dig deep into the problem and where
they are trying to get as a final destination. An easy way to do this is look
them in the eye, smile like John Wayne and say "I have seen this many times,
it's not a problem, in fact, there are hundreds of ways we can slice this, let
me ask you, what are the key business objectives here? How will we be
measuring the success and failure of the project from a business point of
view?" Then they really go into what their problem is, and where they are
trying to go. The idea is to not propose any solutions on the spot (guess
what, they don't like to hear your smarty-pants / clever solutions anyway),
they would like 1) for you to play therapist in the meeting and hear every
last problem, 2) come back to them at a later day and tell them that every one
of their problems will be solved and the cost will be low, 3) be prepared to
explain how it would work (keep high level and leave the clever bits out, but
don't forget to address the impact on other resources like marketing / legal /
etc.) and 4) present to them a timeline of execution mixed with approvals
needed at each stage.

I have fucked up 100 times, and gotten it right about 3, thats how I know.
Hope it helps some wise guy (like I was) out there.

~~~
hurtmyknee
This is great advice that took me quite a bit of time to learn as well.

Most of our meetings are held in a room with a whiteboard, and it has become
standard to start by writing "GOAL: {{goal}}".

It prevents tangents, encourages us to use the scratching space so we can
diagram the high-level components involved, and helps educate the folk who
aren't up to speed (technical or business).

------
magpi3
As far as I can tell everything requested can (theoretically) be done.

As many commenters noted in the original discussion
([https://news.ycombinator.com/item?id=7513182](https://news.ycombinator.com/item?id=7513182))
if you increase the number of dimensions you can increase the number of lines
that can be perpendicular to one another. How a person would "draw" in such a
space is merely a question of semantics.

You can certainly draw a kitten with a line. Just not a straight line. This
definitely complicates the perpendicularity requirement, but I suppose that if
every line is identical (they all draw kittens), then it can be done.

Finally, color is just a question of lighting. You can draw red lines with
green ink. Just draw the lines in one color setting (where the ink is green)
and display the lines to the client with different lighting where the lines
are red. The fact that the lines must be drawn with red, green, and
transparent ink complicates the lighting setup, but it can be done.

The inflation of the red balloon should be trivial but could be delegated to a
less technical member of his staff if necessary.

I certainly don't envy him the task, but Anderson should quit with the excuses
and get to it.

~~~
zackkitzmiller
Lines, by definition, are straight. Otherwise it's a curve.

~~~
baddox
Lines also, by definition, have no beginning or end. They're defined by a
simple equation like y = mx + b. Good luck drawing one of those with _any_
ink.

~~~
dllthomas
_" Good luck drawing one of those with any ink."_

No trouble, since they also have zero width...

------
mikestew
"What exactly is stopping us from doing this?"

"...geometry."

I've had too many conversations like this, where I pause to think "where do I
begin to fill the vast gaps of ignorance such that they will even begin to be
properly equipped to understand the absurdity of their question?"

~~~
tedsanders
Just to add to your response, I think absurd questions are totally OK. It's a
fact of a life that non-experts will need to talk to experts, and when that
inevitably happens it's best if (a) the non-experts aren't scared of asking
potentially absurd questions and (b) the experts can translate their thinking
into non-expert language. Both (a) and (b) are necessary for great
communication.

~~~
mikestew
Generally speaking, I have no problem with absurd questions. Ask away. But if
you're sitting on the other side of the table just waiting to hear what you
want to hear, ignoring all else, and continuing to ask the same questions,
then you're not doing your part on the "great communication" thing. That's my
take on what the video is trying to get across. Too bad cnet editorialized the
title, and incorrectly so, IMO.

------
analyst74
Junior sales will say yes to whatever the client says they want; Junior
engineer will try to implement whatever the client says they want, say no if
it's impossible.

Senior sales will try to figure out the real reason of a client's request, and
sell them a solution that solves their real problem; Senior engineer will try
to figure out the real reason of a client's request, and propose a solution
that solves their real problem.

A sales person and an engineer may start from opposite directions, but really
good ones think the same.

~~~
mildtrepidation
That really depends on your definition of "good" in this context. I've worked
in more than one place where a "good" salesperson is one that brings in the
most revenue, damn the torpedoes, feature creep, impossible requirements, etc.

Sales and engineering have fundamentally different objectives: Sales needs to
generate revenue, engineering needs to create a project that satisfies a
specification (ideally). There is very obviously overlap and hopefully
interplay there, but I don't agree that people who are good at those largely
disparate things necessarily think in any particular way, and certainly not
the same way.

~~~
analyst74
When the type of sales person you mentioned gets promoted and valued, it's a
failure of management, and will eventually lead to failure of the business (it
can take a long time for the damages to surface, however).

In most, if not all industries, reputation of a company matters a lot. That's
how you get repeat and referral business, the lifeblood of a mature business.

------
dang
This was posted yesterday under a different URL and I penalized it. This time,
I'm going to bury it as a dupe.

Because it is designed to elicit controversy (and views) rather than insight,
it is not good material for HN.

We can have a discussion about communication between engineers and others. I'd
have a lot to say about that myself. But priming everyone for indignation
("surrounded by idiots") is exactly the wrong way to start it.

Pandering to engineers who think they are "surrounded by idiots" is not
seeking to get at the truth. It's an appeal to pre-existing opinion, i.e.
prejudice. Worse, it's a sneaky way to promote tribalism while pretending to
promote the opposite (tolerance). HN stands for the opposite of all these
things.

(Side note: when I say "bury", I'm using a technical term from our code. It
means applying a rank penalty, but leaving the item open rather than killing
it, so anyone who wants to can continue the discussion.)

~~~
abbasmehdi
It's a common problem among external facing engineers. A source of great
stress also. I think it is critical for engineers to discuss this topic and
re-shape our view of working with the external world. We don't operate on an
island and we cannot keep going for long with a condescending view of the
business types without developing issues. Figuring out a mutually beneficial /
acceptable operating procedure is key. The default is too negative and helps
no one. With some skill, we can leverage our position, really solve big
problems, and have a better working relationship. Just my 2 cents coming from
b2b where my projects have 100% external impact (i.e. if we fuck up, they will
have egg all over their faces - brings out the control freak in the business
types).

~~~
dang
Sure. That's why it should be discussed in the context of, say, a thoughtful
article, rather than a baity video. If you'd care to post such an article, or
an Ask HN, that would be much better.

Edit: None of what I said applies to your comment, though. How about this?
Post it as an Ask HN with a good title. I'll put the link in my comment at the
top of this page, we can ask rogerbinns and hurtmykneee to migrate their
replies over, and have a substantive discussion.

~~~
abbasmehdi
Thanks for offering an alternative, Dan. Not sure if it's worth the hassle. I
do appreciate your effort.

I would like to point out that the baity video is satirized commentary on many
enterprise cultures. Though the presentation layer is light, the content is
heavy; thus spawning discourse.

------
sly_g
Original short story is in Russian and was written in 2011. [http://alex-aka-
jj.livejournal.com/66984.html](http://alex-aka-jj.livejournal.com/66984.html)

Thought that you copyright lovers ought to know this.

------
mrpoptart
The moment the client's request is determined to be impossible, the only
problem can be communication and the engineer's assumptions must be
challenged. Instead of feeling that he is an "expert," he should try to
understand what the client actually wants. Instead of asking questions to
point out how the client's request is wrong, he could have asked questions
about how to clarify the problem -- "what purpose do the red lines serve?"
"why did you choose green ink?" etc.

~~~
Evgeniuz
But he asked "Can you describe, what the end result should look like?"

~~~
jrochkind1
That's actually completely different though.

I'm always trying to get my internal stakeholders to NOT describe what they
think the end result should look like, but to describe WHY they want it, what
they want to accomplish, and let me help figure out what the end result should
look like to accomplish that.

I'm not saying it's easy.

------
shmerl
Not necessarily idiots. Just those who don't know what they don't know.
Knowing what you don't know (and therefore not overstepping one's bounds when
making judgements) is an important thing.

~~~
yoha
I think the point is not so much about the fact that they do not have a firm
understanding of the field, but that they are just blatantly ignoring the
viewpoint of the Expert, who is supposed to be the authority with regards to
feasibility.

------
shmerl
It also reminds me this:
[http://dilbert.com/strips/comic/1995-11-17/](http://dilbert.com/strips/comic/1995-11-17/)

------
yuchi
I’m pretty sure most of the other comments are pointing to what I‘m going to
say too, but I have to put this out of my mind.

This video, while hilarious, puts the ‘expert’ not in a good light. It is in
fact true that the ‘customer’ is talking completely nonsense, but it’s not her
fault. Most time you’ll be dealing with something which 1) has been put there
or 2) has a focus on something else and you‘re are the only ‘tool’ to
accomplish her goal.

The question is: what’s __our __goal? Engineering for the engineering’s sake?
This is a goal that IMHO __must be present __in every engineer, this makes us
mutate from tools to artists (personally I think that if something happens for
its own sake, then that’s art) But this must (IMHO) not be the only one. What
we really need as a goal is something anthropocentric: make someone else happy
(happier).

The real problem here is not in the customer, but in the ‘expert’. If you
really want to have that ‘expert hat’ what you really need to do is
__understand __the very person you have in front, and her needs. Only then you
can start talking about ‘technologies’.

The problem with this video is that the customer is asking for something __to
be done __, and the ‘expert /sales-men’ team responds with “hows”, this moves
the conversation in the wrong direction.

\- “We need you [...] to draw 7 perpendicular lines” \- “Could you please
explain better what was the process that brought you here?”

If the sales-man stops you because this kind of questions is ‘out of scope’ of
the meeting, ask him out, and destroy him to the very last piece of him: he
must let you do your job (understand the customer’s needs and take them from
want-space to real-space), his job is ensuring that from a sales and customer
relation point of view you‘re not ruining your own company strategic plans. Is
he also the project manager? Then try to make him reason. He doesn’t? Quit.
Now.

wooosh. I had to say it. sorry.

~~~
mildtrepidation
This is really, really idealistic. Most people _do not_ have the flexibility
to just up and quit, and most people in this situation _do not_ have the
influence to "destroy" a salesperson without getting fired or at least
censured.

It sounds like either you've never been in a situation like this or you should
back up a bit and take it in at a higher level; you're missing the forest for
the trees. You're assuming the client contact you have even _knows_ "the
process that brought [them] here," which they often don't, and that they are
going to be interested in discussing it with you, which they often aren't,
among other things.

This conversation is also more often, in my experience, one step removed:
Rarely have I seen this actually happen with a technical implementation person
in the room. More typically it's a salesperson and a project manager, and you
just get marching orders after the fact, which may or may not make sense
depending on the PM's ability and willingness to make sense of the client's
requirements.

------
ColinWright
Extensive discussion:
[https://news.ycombinator.com/item?id=7513182](https://news.ycombinator.com/item?id=7513182)

------
6d0debc071
"That's a triangle."

Shut up, you fool, _it 's what the client's asking for._ Get them to add a few
more lines and then order coffee.

------
mightybyte
I had a version of this happen to me at my first job a few months out of
school. I was supposed to write code to read IMU data from a flying sensor.
The sensor was giving me a stream of pitch, roll, and yaw numbers, and I had
to use this information to convert sensor measurements into absolute
coordinates in lat, lon, and altitude. As is so often the case, there was no
documentation on the data format coming from the IMU unit. I had no idea
whether the numbers were in radians, degrees, gradians, or some other weird
format. I also didn't know what order the pitch, roll, and yaw transformations
should be applied in.

So in a team meeting I asked about the transformation order. Now, pitch, roll,
and yaw transformations are not commutative. For the small angles that you're
likely to see in typical flight, they're _almost_ commutative, but of course
we were trying to do better than "almost". But when I asked about the
transformation order, someone answered that it didn't matter. These were
actually some technical people who answered, so it wasn't even management
talking ignorantly. I politely said that it's a mathematical fact that order
does matter when applying pitch, roll, and yaw transformations. The guy
responds, "Oh no, the IMU measurements represent a snapshot in time." I
responded that in that case, the numbers carry with them an implied
transformation order, and that I need to know what it is in order to write my
software correctly. "No, I'm pretty sure it doesn't matter," he said. Now I'm
getting desperate, so I bust out with the hand demonstrations. "Start here,
pitch up 90 degrees, then yaw right 90 degrees. Now compare that to yaw right
90 degrees, then pitch up 90 degrees. See? We started from the same
orientation, but we get different results." These guys weren't having any of
it. They insisted that it didn't matter, so I dropped the issue. Later I
brought it up again at another meeting and a PhD who wasn't in the first
meeting says, "Oh, I know what you're talking about." Ahhhh, finally,
vindication.

That didn't even help me all that much though, because nobody seemed to have
information about the actual ordering. I think in the end I had to reverse
engineer it by brute forcing every possible combination of units and orderings
until I found one that made the data look right. And oh by the way, the units
weren't in degrees, radians, OR gradians. They were in units of semicircles,
where 1 = 180 degrees.

------
saadhus
On the other side of the coin, I am not really an engineer and have worked
mostly in project management or marketing, working with engineers. And I have
to say, this type of thought is why everyone tended to avoid dealing with
engineers as much as possible.

There is quite often this mindset of superiority amongst the engineering
community and it only serves to isolate them further. Engineers aren't all
knowing, and everyone else aren't brainless morons. While engineers might know
engineering, the marketers know marketing, the salesman know sales, the
financiers know financing and so on. It takes great collaboration among
everyone to make a truly great product and to have it really make an impact.

So, please, if you can, avoid this "surrounded by idiots" type of thinking.
Everyone is working towards a common goal, and the sooner we realize that we
aren't better than anyone else, the sooner we can achieve our goals.

------
cyphunk
As an engineer i tire of engineer worship. Any engineer not too full off
themselves should finish the video with too conclusions perhaps unintuitive to
much of the HN mass:

1\. I could actually fulfil the letter of the request provided I can use 2 red
lines, 2 green lines and 2 transparent lines. Or I could modify the request
slightly in various ways to also provide much of the requirements.

2\. damn if it was not for the stupid sales people I probably would not have
even thought of these solutions.

Non-techs are there to force you to think outside of your own damn box. Too
many engineers assume that people talking to them should understand why
something wont work, before they take the time to see how it could work
differently then even they would have initially thought. Even fewer have the
wits to give credit to the collaborative process that brings these less that
intuitive solutions to light.

Go find and read the circa 1700 essay
[https://en.wikipedia.org/wiki/Heinrich_von_Kleist#On_the_Gra...](https://en.wikipedia.org/wiki/Heinrich_von_Kleist#On_the_Gradual_Production_of_Thoughts_Whilst_Speaking)

------
NAFV_P
This reminds me of trying to explain how left handed scissors function.

Give 'em a piece of paper with a straight line down the middle and a pair of
right handed scissors, then instruct them to cut accurately along the line
using their left hand. Afterwards ask them why they are holding the scissors
on the right hand side of their body.

------
rndatoz
7 parallel lines can be achieved by creating an 8-dimensional Riemann space
(R8) and then drawing in it. The bill for the particle accelerator to do so is
on the order of $1,250B. We'll just assume that you're OK with this and add
that to the project budget -- invisible Red and Blue ink, easy. Phosphor dyed
UV ink. No problem. It will perfectly meet your specification.

If you want the visualization and detailed description of the solution, we can
engage Rand Corp for a nice slick to show you how this will work. It'll be
about 1250 pages, and we can add this to the budget for a little over $400M.

\--

If there's any lesson to take from this... When confronted by people who don't
understand the scope of the problem -- don't communicate the problems OF the
problem. Communicate the actual scope of the solution. It will tend to focus
the dicscussion rather rapidly.

------
lifeisstillgood
This seems like self-serving drivel. Engineers are not Gods and non-engineers
are not single-digit-IQ morons.

The tasks set is of course impossible by definition - which is not the case in
the real world where most projects are doomed by human factors, lack of trust
and will rarely if ever be rescued by one guy standing up and saying "No you
are all wrong now listen to me and I will tell you why this cannot happen".

Humans work emotionally and love stories - if we want to succeed and still
fulfill out inner Maker then instead of No you can't do it, please try
"Instead of red lines why don't we sell pencils to enable our customers to
draw their own lines. What's the best ad campaign we can imagine for a pencil
case aimed at the blue collar market?"

Everyone else is not an idiot, is probably the best and most useful thing to
take away from this.

~~~
smileysteve
While a little of this clip suggest idiocy - The per... per... dick... dick...

This video is actually more about the human factors in communication. The "you
do know what translucent means" is an example of speech that is VERY absolute
and inflammatory. The sales and PM are very agreeable to the client and
distrusting of the engineer - very often putting the burden of his "being the
expert" against him in the conversation.

------
logfromblammo
I idenitified so strongly with that video that I had to check for hidden
cameras.

------
daveslash
Videos like this make me feel so much better because: (a) I know that I'm not
alone in my frustrations (b) I realize that things could be much worse, and I
should consider myself lucky they're not.

------
whyme
This may appear spammy, but I found Kepner Trego training[1] to really help
prevent this kind of stuff from happening. The strategy is more effective when
everybody in the room has had the training, which limits its usefulness with
external clients, but I'll still recommend it anyway.

1\. [http://www.kepner-
tregoe.com/pdfs/pubworkbro/psdmbroch06-07....](http://www.kepner-
tregoe.com/pdfs/pubworkbro/psdmbroch06-07.pdf)

------
analog31
Granted, the video was funny because it rang true.

I've also been in meetings where the expert was wrong.

Still, I suspect it's not just engineers. The same thing can happen to any
expert in a subject where things can be true or false. For instance, it could
be a legal or financial expert being asked to approve something that's
illegal.

------
riazrizvi
This reminds me of how software engineers have a tendency to see their
viewpoint as the only correct viewpoint.

Source: Veteran software engineer.

------
TheBiv
Idiots is pretty harsh. They could just be focused on other things and not
know the right words to communicate what they want.

~~~
DougBTX
Yea, that's fair. They could want something impossible, or they could want
something possible but are describing it so imprecisely that what they end up
asking for is impossible. They may not be able to tell the difference between
the possible and the impossible, the tech guy can help there.

------
elwell
It's helpful to remember that the role of idiot might be swapped depending on
the topic.

~~~
mkr-hn
As a writer, I get to watch engineers humble themselves in advice forums when
they need to write something important. It reminds me that even the mortal
deities of our little civilization have shortcomings.

------
nsxwolf
I have never worked with business people who were this stupid.

------
awkwit
This hits far too close to home...

------
nolite
or just draw the lines on a globe (like longitudinal ones). and use infrared
ink

------
leishulang
the solution is to idiotized the engineer!

~~~
drdeadringer
... My brain is now trying to combined the songs "London Bridge Is Falling
Down" and "Ring Around The Rosy".

------
ThatGeoGuy
I think that as a metaphor, this video somewhat describes what it's like to
work with somebody who is far beneath your expertise level in the same field.
The obvious bikeshedding aside ("It's just 7 lines, anyone can draw that
Anderson, you're an EXPERT"), working with people who haven't had the same
exposure or experience to problems within your domain before might make you
feel the same way Anderson's character did when he tried to explain why the
task was not (in the most direct sense) possible.

I assume this probably goes both ways. In the eyes of an expert, they'll
probably have difficulties or at the very least get frustrated that people are
making judgment calls when they're obviously wrong. On the other end, non-
experts might actually feel frustrated feeling that the expert doesn't know
what they're talking about, when task X is so obviously a possibility and
they're just viewing the world inside their own tiny box. From both sides,
they lack/forget/have lost the context to see the other sides' perspective.
It's not so much that haughty managers and salespeople are too quick to say
'yes' all the time, but rather that what's obvious to you is clearly not
'obvious' or may not even register within their perception of the world.
Ultimately, the root cause of the problem here is that there are unspoken
assumptions, and neither party is willing to communicate what those are.

Take for example, the assumption that "you're an expert." In reality, you may
be the best in your field, or at the very least you might be well-versed in
it, but an expert in astrophysics isn't going to fare well in a discussion
about civil engineering. In the same way, there are people who make the
assumption that there is no distinction between engineers, and that electrical
engineers are the same as geomatics engineers are the same as chemical
engineers. While the specific field of engineering may be different, small
assumptions that go un-communicated like this are how these sorts of problems
start.

That said, even communicating these assumptions to others may not solve the
problem. In my own experience, I've had problems getting team members up to
speed, if only because there's no hard and fast way to do so. As an example,
when working on a Javascript project with a partner once, my team member kept
complaining that they didn't "get" how to write code in Javascript, despite
having gone through the same education (same degree/program) that I did.
Certainly I had more experience with the language than they had, but I was
confused as to why they would find the language hard. To give some context as
to why I couldn't understand why my team member was suffering, we take courses
in programming with C++ / MATLAB in our first few years within our degree.
Furthermore, I had sent multiple links to courses such as CodeAcademy, and
many others, which I had assumed would have given my partner the information
necessary to transfer their skills to the constructs of the new language.

Unfortunately, it didn't work out as I had expected. They continued to
struggle with Javascript, for reasons beyond my understanding. The intent to
learn was there, but for some reason there was no way to explain the language
in a commutable way to them. And here's where I noticed the problem of being
an "expert" who's "surrounded by idiots": I couldn't get figure out why
someone who had the same basic training/purported skills as me couldn't manage
something as simple as learning a new programming language. At the end of the
day, there was definitely a communication barrier, but the "unspoken
assumptions" I spoke of before didn't even help alleviate that once they were
revealed. I guess in this case, once I had set that barrier, it wasn't coming
undone. The attitude that "this is too hard" or "I can't do this" had already
set in, so there was little left I could do about it. Even attempting to help
teach after the fact was only met with disdain and harsh attitudes.

If anyone else has some tips for dealing with this sort of behaviour /
attitude / whatever in the workplace, I'd love to hear them. Too often am I
approached by a colleague who tries to convince me of the impossibility (or
possibility, in the case of the video) of some task that is not such. What do
you do when you're the expert and you can't get people to work up to the level
you're on, and what do you do when you're the non-expert and feel like the
level you need to work up to is impossible?

------
notastartup
I was thinking god this video is boring, talking about colors and lines, how
is relevant to tech, then the monstrosity of it all hits me, this is what I've
been doing many many times.

