Since this article starts with $$ values, I’m not sure if the effectiveness of engineers is even related. It has lots to do with the nature of the product and business. Yeah you could build crypto exchange or maybe Instagram with a dozen engineers, but good luck with that for more complex product like AWS, Tesla. The key IMO is a successful business can be technically simple to start with, but it could rarely stay simple for too long
What Makes an Effective Engineer?
11–15 of 15 posts
Re: What Makes an Effective Engineer?
#12I always got rejected by big tech, even when I passed their algorithm questions. They said I’m not there yet on leadership stuffs. Now I work in a private trading firm instead. The best company ever I’ve encountered, and really smart people that I’m sure could run around in circles against big tech employees. Good work life balance. Can do WFH whenever wherever. Good food. Less bureaucracies, less meetings. No middle…
hiring?
Re: What Makes an Effective Engineer?
#13I always got rejected by big tech, even when I passed their algorithm questions. They said I’m not there yet on leadership stuffs. Now I work in a private trading firm instead. The best company ever I’ve encountered, and really smart people that I’m sure could run around in circles against big tech employees. Good work life balance. Can do WFH whenever wherever. Good food. Less bureaucracies, less meetings. No middle…
hiring?
Yes, DM me.
Re: What Makes an Effective Engineer?
#14Re: What Makes an Effective Engineer?
#15I am a former engineering operations manager with 30+ years of high-tech product development experience in both hardware and software. I would define an effective engineer as one who can: A) work together effectively with other engineers, scientists and team leaders; B) define the problem being solved in detail (requirements) through thorough investigation and analysis; C) devise a safe, cost-and-time efficient solut…
Say I give you a box with 1,000 puzzles written on sheets of paper, and I ask you to estimate how long it will take to solve all the puzzles. You take out a small random sample and time how long it takes you to solve each, and then you develop a cost distribution from that, scale it up to 1000, add a healthy 2-sigma buffer on top, and tell me you're 95% certain you can solve all the puzzles within that time. You've accomplished your step D. Oops, on one of the papers was the Collatz Conjecture, so you're fucked, I'm fucked, everyone's fucked, everyone's unhappy, and you get fired.
Your steps work great in an idealized perfect world where everything is simple, and they are absolutely awful, bloated, and ineffective in the real world. The perception that this is what engineers should be contributes to why a huge percentage of real-world projects go over-budget by triple-digit percentages, get cancelled entirely, or completely fail to live up to their expectations.
It's quite the other way around. If you're doing something new, you just don't know everything yet, so you simply cannot do this monotonous waterfall method. You can only do this with well-known problems that have well-established solutions. If you define an engineer as someone who is producing a practical solution to a problem that has never been solved before, at least in this exact way (on this site, in this heat, at that speed, at this scale, within that organization, etc.) then you have it exactly backwards -- anyone who follows this process is a technician, solving a problem by following an SOP or a textbook or a WikiHow article. Engineers realize this is all just dumb bullshit they have to do that takes their time away from actually exploring, understanding, and ultimately solving the (probably different, by this point) problem.