Lauris Beinerts
20 HN mentions · mentioned in 19 months, 2014–2025
7:35 · 33M views · Mar 23, 2014
A comedy sketch of a business meeting in which an engineer, the expert, is asked to do impossible things like draw red lines with blue ink.
Shared constantly as a painfully accurate depiction of absurd requirements, clueless management and estimation pressure.
20 comments from Hacker News
I really enjoyed the post. I reminded me a lot of this Youtube video( this video ). I understand this is a comical post but as the son of a carpenter and understanding the profession decently well I would say these are none of the questions that would be asked of a carpenter. There are however many important questions a person would need to answer to be hired as a carpenter or more likely be able to join a union. There they would be able to get experience and training. Then the company the union carpenter work for already knows the skills and abilities they have and there is really no need for any interview. Any GC or sub asks for guys to do a job. The local sends them the qualified guys. Pretty simple actually.
> somebody said that a thing is simply not possible and a manager asked "but what if it was possible?" I've been an Individual Contributor, and a Manager, and am back to being an IC. I've been on both sides of this conversation. One of the benefits of being a manager is being able to see the forest from the trees while your team members may be so focused on their tasks they do not see the big picture. Sure, sometimes the answer to "but what if it was possible?" if just "it's not." But a lot of times, the good managers I've had would propose an approach to MAKING it possible that I just simply didn't see. And I've been able to do the same in their shoes. Sometimes it requires a paradigm shift - Q: "How do we get to the other town faster?" A: "The horses are running as fast as they can" Q: "What if we found a faster horse?" (e.g. a car) But honestly in day to day office culture it rarely needs to be so revolutionary - Q: "Could we finish the project faster if Bill's team helped us?" A: "No, it's not possible. Bill's team said they are completely swamped" <Goes off to do some managerial work> Q: "Okay, I've chatted to Bill, and his team is fully available to help us finish the project." I'll leave you with this "Expert" saying that something is simply not possible: this video And an actual expert showing how it can be done: [LINK]
Completely agree. They don't flub around trying to figure out and contextualize issues. They're able to both categorize the issue and the disagreement and present in ways that everybody can consume.* We're not all so lucky, though. Many times I've had to tell teams "This is going to sound right. Please forgive me because I'm concerned about X". You can't replace that kind of give-and-take with wordsmithing. The second skill I've noticed is to be a storytelling master. Great leaders tell engaging stories that emotionally draw you into their way of seeing things. *A problem occurs when the leader thinks they know what's going on but they are mistaken. In this case better leadership skills can actually lead to poorer overall results. I've seen good people with mission-critical ideas get "facilitated" out of them by well-meaning, nice, and intelligent people who don't know what the hell they're talking about and are unable to accept that fact. Obligatory link: this video
>If you did your job right, you have people that are much more experienced than yourself. "You hired me as your UX expert. I use A/B trials, prior trials, studies, and knowledge I've pieced together over the past 20 years." The question of "What are you even paying me for if you're going to ignore my advice?" is one I'd love to ask but fear getting fired for pointing it out. The alternative to micro-managing is asking for the impossible [0]. Which also happens frequently. I was once asked to make a transparent .jpg because .png are "too heavy". I had to explain how .jpg's work, tell them I could make it a .gif, but that the .png compressed better and would be more lightweight than the .gif. They insisted on the .jpg at which point I gave up, matched the jpg's background color to the blue background they had and saved it as a .jpg. Which turned out to still be a bigger file size than the equivalent .png. [0] this video
Any analysis of a problem, requires understanding WHAT problem needs solving. The issue in real world is, buisnesses and markets (as well as technology) are changing very fast, and any in-depth analysis done two years ago might not have the same outcome as if done today again. This is a fundamental realization of agile. If you have a problem domain which is not subject to change, waterfall might be the right choice. But you almost never have that. I know it is hard to accept for us devs, often with backgrounds in Math/Physics/CS etc. because the problems we were trained to tackle there are always the same, and the laws of math and physics tend to never change (or change way slower than in modern markets). Relevant clip perfectly highlighting the problems you have during requirement analysis: this video