Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Effective Engineer – Notes

gist.github.com

Post reply on HN
Print view View original

141–150 of 236 posts

Re: Effective Engineer – Notes

#141

Post by brucephillips »

edmondlau wrote: post #125
nostrademons wrote: post #114

Earlier quoted context omitted.

But without the benefit of hindsight, how do you tell the difference? When I look at some of the giant wins of the last major tech wave, often times the key factors in their success were external events that happened after the formation of the company. AirBnB benefitted massively from the housing bubble & financial crisis (3 years after formation), which created a large class of people who were desperate for income a…

I like the bottom-line perspective you provide at the end, of "success = preparedness + luck." Preparedness is what we can train ourselves for, and preparedness also has the effect of making you more able to see and take advantage of opportunities that come your way. And to someone who doesn't know how much you've prepared, it appears that you're just luckier.

But these examples are cherry picked. Was Google lucky? Oracle? Hotmail? Take away what luck might exist, and would they not still be billion dollar companies?

Re: Effective Engineer – Notes

#142

Post by ashwinaj »

edmondlau wrote: post #11

Hi! I'm Edmond, the author of the book. Happy to answer any questions about my two-year journey in self-publishing the book.

Hi Edmond, your book was great and I enjoyed reading it!

I do have a question on your topic on high leverage work; as a startup how would you know what is high leverage work? You have talked about various tooling projects at Quora which turned out to be duds, but how would you know that beforehand without trying? I guess the same applies to your book...

Re: Effective Engineer – Notes

#143

Post by bsder »

joshuamorton wrote: post #80
bsder wrote: post #76

> 80% of the impact comes from 20% of the work. This simply has no basis in reality nor research and it pains me to see it propagated. The old VLSI design koan is: "The first 90% of the project takes 90% of the schedule. The last 10% of the project also takes 90% of the schedule. 90% of the engineering occurs in the last 10% of the project."

Yes it does. The 80/20 rule cleanly fits an exponential distribution. The assumption is then that the work to implement any given feature in a project follows an exponential , and this appears to hold reasonably true in practice.

All you did was move the question--why does this thing fit an exponential distribution?

The birth project of agile--the Chrysler Comprehensive Compensation project--should have been a wonderful example of the 80/20 rule. They implemented the most important chunks of the project and got about 80% of the cases correct--totally awesome.

Except--it wasn't. The value of the project was in handling all of the exceptional cases. And those cases started consuming VAST quantities of resource.

80/20 only works when you can interchangeably wipe out tasks without affecting the result. Most engineering is NOT like that.

Analyzing the soil may not take very long when building a bridge, but you can't skip it.

Re: Effective Engineer – Notes

#144

Post by badminton1 »

I think that the understanding of software engineering as an occupation is a bit oversimplified.

While there are good chances most people will be working on web or mobile applications, there's much more going on. Compilers, cryptography, compression, operating systems, graphics, simulation, data retrieval, distributed systems, etc. To that you need to add machine learning and AI.

I think it is hard to come up with a unified set of tactics/strategy to be an effective engineer at each part of this occupational spectrum.

For example, some engineers, while learning, try to specialize themselves in an area while others try to become generalists. Both approaches can be valid depending on the role.

Some engineers focus on applied science while others on theoretical science, some others just on empirical knowledge, processes and techniques. Again, the impact of this decision will largely depend on the role.

Then, prioritization is a double edged sword. To do what is perceived as important is intuitively the right thing to do. But during learning it is harder to recognize what is important. This is how many people end up neglecting valuable learning.

Re: Effective Engineer – Notes

#145

Post by IronKettle »

dualogy wrote: post #140
IronKettle wrote: post #111

Earlier quoted context omitted.

I've heard multiple similar arguments in favor of the word "synergy" or "paradigm". Let me turn the tables: Why is "leverage" acceptable to use but "synergy" engenders scoffing?

I'll take that table-turn! Well my intuition here goes like so: think back to the first moment in life you heard about a "lever" --- then "synergy". Chances are, the former was an illuminating childhood moment when simple levering was first powerfully demonstrated to you by a peer or parent, and tickled your inner engineer/fixer-upper/tinkerer. Chances are, no comparable "engineerish" moment occurred when you first e…

Probably the wrong person to ask :). The first time I heard the word "synergy" was downloading https://symless.com/synergy , which was an incredibly useful piece of software and absolutely did tickle my inner engineer (trying to figure out how it worked).

Re: Effective Engineer – Notes

#146

Post by joshuamorton »

bsder wrote: post #143
joshuamorton wrote: post #80

Earlier quoted context omitted.

Yes it does. The 80/20 rule cleanly fits an exponential distribution. The assumption is then that the work to implement any given feature in a project follows an exponential , and this appears to hold reasonably true in practice.

All you did was move the question--why does this thing fit an exponential distribution? The birth project of agile--the Chrysler Comprehensive Compensation project--should have been a wonderful example of the 80/20 rule. They implemented the most important chunks of the project and got about 80% of the cases correct--totally awesome. Except--it wasn't. The value of the project was in handling all of the exceptional c…

As far as I can see, what you described perfectly fits the 80/20 rule.

Re: Effective Engineer – Notes

#147

Post by yanilkr »

yanilkr wrote: post #4

This is effective nonsense. Based on my personal experience, effective engineers I know do not follow a formula like this. This looks like a list of how to be teacher’s pet. A superficial need to be praised by others as effective only takes to “mediocre”.

I will try to elaborate without trying to insult anyone. It might be harsh but I am sure the author can handle it.

First of all look at this sales copy of the book. https://www.effectiveengineer.com/book

It looks like a weight loss e-book product designed to trick ambitious people into impulse buying. It tries to build credibility by name dropping "google", "facebook", "insert big company here" every other paragraph. Then there are testimonials about how great the advice is from "LeaderLeaderLeader" enterprise hierarchy pattern i.e people with big titles from popular silicon valley companies.

Everything in that page is designed and optimized to make you buy the package. For a price of 250$ you too can know the secrets of effective Engineers.

To sell this content first create and exploit an insecurity in jr.Engineers or fresh job seekers in technology by saying they are not an effective engineer unless they buy this book/package and read the content and then they too will be part of the club and work at a big name brand company. Some people in our work places are exceptionally good at social engineering and not so much in actual engineering. The sales copy co-opted the "engineering" discipline to sell some curated content. This looks much similar to team/company "politics".

I do not think people in "effective engineering" business do this. This is certainly what people in content business do.

Now compare that to some other book for a contrast. https://basecamp.com/books/getting-real

Engineering is just like any other skill for e.g., like playing chess or piano or swimming etc. You get better by doing it many times and failing often. To be good at engineering involves many factors like genetics, discipline, irrational love and passion for a particular domain, patience, exposure to better ideas and better people. Even you are good at engineering, to be effective at a company/market, you need to know the right people and have right social and financial skills to get name and recognition.

Some how, effective engineering has become synonymous with what happens at big name company teams which I think is very wrong. If you look at the real world, once companies reach a bigger size, they stop doing effective anything. They just buy other small companies which spend more time on making effective products.

This content seems to be analogous to "founders at work" but a better title would have been "engineers at the enterprise".

Re: Effective Engineer – Notes

#148

Post by michaelt »

brucephillips wrote: post #84
edmondlau wrote: post #48

Earlier quoted context omitted.

Your observation is a great one, and I'd love to see more data on this as well. A related point, though, also rings true. Soft skills like being a good coach and effective listening are so underinvested in, that even marginal improvements in those skills lead to huge differences in success. I see this in engineering leadership workshops that I've run with Jean Hsu and Diana Berlin, where even teaching a handful of co…

Do you have any ideas on how companies can better assess soft skills during interviews?

Do you just want something that assesses soft skills?

Or do you also want something where all your interviewers will give the same candidate the same score, and that's robust against being gamed?

The former is easy: "Tell me about a time you helped a colleague improve their performance", "What do you think makes for a good coach?" etc etc.

The latter? I've never seen a convincing way of doing it.

Re: Effective Engineer – Notes

#149

Post by brucephillips »

yanilkr wrote: post #147
yanilkr wrote: post #4

This is effective nonsense. Based on my personal experience, effective engineers I know do not follow a formula like this. This looks like a list of how to be teacher’s pet. A superficial need to be praised by others as effective only takes to “mediocre”.

I will try to elaborate without trying to insult anyone. It might be harsh but I am sure the author can handle it. First of all look at this sales copy of the book. https://www.effectiveengineer.com/book It looks like a weight loss e-book product designed to trick ambitious people into impulse buying. It tries to build credibility by name dropping "google", "facebook", "insert big company here" every other paragraph.…

> To sell this content first create and exploit an insecurity in jr.Engineers or fresh job seekers in technology by saying they are not an effective engineer unless they buy this book/package

Where are you reading this?

Re: Effective Engineer – Notes

#150

Post by xstartup »

makecheck wrote: post #39

On the topic of reading code “written by brilliant engineers”… Code bases can be so large that you might find brilliantly-written things intermixed with things that are not brilliant (and some of those parts may even have been added by the brilliant engineer on an off day). Therefore, it’s risky to just absorb an entire blob as Good without also understanding its history. An interesting side effect of languages/ecosy…

People often don't realise the person who improved the codebase within a short span of time had years of experience in the domain. I know a class of engineers who are solving the EXACT same problem using the EXACT same method from from company to company. To someone from outside, it might appear like they are job hopping looking at their average time spent at a company.
Post reply on HN