4 ms·

Some of the comments here claim this is just showing how engineers think they are the only smart ones, or how there's equal frustration pointed back at engineer

by chavesn 13y ago

Some of the comments here claim this is just showing how engineers think they are the only smart ones, or how there's equal frustration pointed back at engineers. 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. This particular weight doesn't fall on any other role. It's easy for anyone, including engineers, to misjudge a problem when simply talking about it. This makes non-technical meetings about technical problems particularly difficult. But yes, it's true, every role has stereotypical flaws, and it's healthy to be able to laugh at them[1]. [1]: http://i.imgur.com/YiuSeRE.png http://i.imgur.com/YiuSeRE.png [2, edit to address comments]: Only affects engineers, of all the roles in a work pipeline involving engineering.

gatehouse 13y ago
I wouldn't be surprised if accountants are also affected. There's something so excruciating about acting as a hypothesis checker for hours while the people in the room gradually develop the knowledge they need to solve their own problems because they don't trust you enough to delegate.
rtpg 13y ago
In a very meta twist, your comment reads with a slight undertone of "engineers are the only smart ones." Engineers might end up with the keys to the servers, but many problems (and solutions to them) are not very technical. Things like the copy on landing pages, or customer support workflow, and many other problems businesses can face are only technical in that at one point an engineer will do something. But it's not just engineers that have this problem. Designers can get them, marketers can get them , etc. Any opportunity for there to be cognitive dissonance will be exploited by Murphy's Law to make people's lives like this
einhverfr 13y ago
I thought this was a very funny video, not because of the reasons you are articulating but because it underscores a very real problem, namely that people come in with unrealistic expectations and can't understand why they are unrealistic. This being said, I don't think this is a problem specifically related to engineers. I think it affects nearly every specialist who is tasked with a vital role outside of the general knowledge. Accountants, particularly cost accountants, would be my second thought for a profession that must be in a similar position. Doctors and lawyers also come to mind. In the end, I think it is funny because the problems are framed in a way we specifically can relate to, not because the problems uniquely affect engineers.
whyme 13y ago
> However, this is illustrating a particular problem that only affects engineers -- engineers are the ones at the end of the day who have to make a solution reality. This is simply not true. In the past I was a Business Analyst. I would meet with clients to gather requirements and that illustration would often unfold in the same manner. It has nothing to do with a persons role, it has everything to do with having large knowledge or expertise gaps.
- deleted 13y ago
  [deleted]
- Swannie 13y ago
  Having been a developer, contract developer, consulting analyst, and consulting architect, I can say you are right. There are challenges for business analysts, similar to this. But it's not the same league. Technology often comes down to "it can be done" or "it can't be done without a lot more effort than you are willing to pay for". Sure, a business analyst may have similar problems ("this process works" vs. "this process would take 5 people a week, each time - but we only have 1 person for 4 days"). However you, the business analyst, are not usually then expected to go away and actually make X happen - you hand over your requirements to other people for them to "make it happen".
  - whyme 13y ago
    So you think BA's can not learn, even through experience, what can or can not be done? Sure, there's always somebody else, same role or not, who has more expertise, but don't confuse role/title for expertise. I've seen BA's with a decade of experience school junior engineers on what can or can not be done.
    - Swannie 13y ago
      No, that's not what I'm saying at all. 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.
grey-area 13y ago
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).
- njbooher 13y ago
  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.
cbsmith 13y ago
I'm sorry, but it actually effects anyone who is in individual contributor. Even with the caveat for "a work pipeline involving engineering". Linguists doing translation run in to it, designers run in to it, document writers run in to it, even individual sales folks run in to it.
dagw 13y ago
engineers are the ones at the end of the day who have to make a solution reality That's rarely true. More often than not engineers hand off their plans to lowly underling programmers/technicians/builders/craftsmen who are the ones who actually have to make thing a reality.

by chavesn 13y ago

gatehouse 13y ago

I wouldn't be surprised if accountants are also affected. There's something so excruciating about acting as a hypothesis checker for hours while the people in the room gradually develop the knowledge they need to solve their own problems because they don't trust you enough to delegate.

rtpg 13y ago

In a very meta twist, your comment reads with a slight undertone of "engineers are the only smart ones." Engineers might end up with the keys to the servers, but many problems (and solutions to them) are not very technical. Things like the copy on landing pages, or customer support workflow, and many other problems businesses can face are only technical in that at one point an engineer will do something. But it's not just engineers that have this problem. Designers can get them, marketers can get them , etc. Any opportunity for there to be cognitive dissonance will be exploited by Murphy's Law to make people's lives like this

einhverfr 13y ago

I thought this was a very funny video, not because of the reasons you are articulating but because it underscores a very real problem, namely that people come in with unrealistic expectations and can't understand why they are unrealistic. This being said, I don't think this is a problem specifically related to engineers. I think it affects nearly every specialist who is tasked with a vital role outside of the general knowledge. Accountants, particularly cost accountants, would be my second thought for a profession that must be in a similar position. Doctors and lawyers also come to mind. In the end, I think it is funny because the problems are framed in a way we specifically can relate to, not because the problems uniquely affect engineers.

whyme 13y ago

> However, this is illustrating a particular problem that only affects engineers -- engineers are the ones at the end of the day who have to make a solution reality. This is simply not true. In the past I was a Business Analyst. I would meet with clients to gather requirements and that illustration would often unfold in the same manner. It has nothing to do with a persons role, it has everything to do with having large knowledge or expertise gaps.

deleted 13y ago
[deleted]
Swannie 13y ago
Having been a developer, contract developer, consulting analyst, and consulting architect, I can say you are right. There are challenges for business analysts, similar to this. But it's not the same league. Technology often comes down to "it can be done" or "it can't be done without a lot more effort than you are willing to pay for". Sure, a business analyst may have similar problems ("this process works" vs. "this process would take 5 people a week, each time - but we only have 1 person for 4 days"). However you, the business analyst, are not usually then expected to go away and actually make X happen - you hand over your requirements to other people for them to "make it happen".
- whyme 13y ago
  So you think BA's can not learn, even through experience, what can or can not be done? Sure, there's always somebody else, same role or not, who has more expertise, but don't confuse role/title for expertise. I've seen BA's with a decade of experience school junior engineers on what can or can not be done.
  - Swannie 13y ago
    No, that's not what I'm saying at all. 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.

grey-area 13y ago

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).

njbooher 13y ago
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.

cbsmith 13y ago

I'm sorry, but it actually effects anyone who is in individual contributor. Even with the caveat for "a work pipeline involving engineering". Linguists doing translation run in to it, designers run in to it, document writers run in to it, even individual sales folks run in to it.

dagw 13y ago

engineers are the ones at the end of the day who have to make a solution reality That's rarely true. More often than not engineers hand off their plans to lowly underling programmers/technicians/builders/craftsmen who are the ones who actually have to make thing a reality.