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

101–110 of 236 posts

Re: Effective Engineer – Notes

#101

Post by rifung »

quadcore wrote: post #44
edmondlau wrote: post #16

Earlier quoted context omitted.

It's less about management and technical ability, and more about soft skills and hard skills. A recent Washington Post article shared an analytical study from Google on what made engineers at the company successful: "Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Goog…

The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas." That is describing what it takes f…

By group of men are you using that like group of people or are you saying it's specific to males?

Re: Effective Engineer – Notes

#102

Post by dejawu »

IronKettle wrote: post #3

This is totally an incomplete thought, and I'm not trying to be down on this author in particular: It's interesting to see a lot of management thoughts and colloquialisms slowly creep into the "other side" of software development (i.e. the actual developers) and become fairly well-tolerated. We still make fun of phrases like "paradigm" or "synergy", but we're all mostly on-board with phrases like "own " or "growth mi…

This frustrates me greatly. Many "engineering management" professors will show Dilbert strips and Office Space memes, then immediately fall into using the same kind of vocabulary that these works mocked.

(Recall that Initech in Office Space had "Hawaiian Shirt Fridays" - one of the core features of this manager-speak is to try to appear human and relevant as much as possible.)

Re: Effective Engineer – Notes

#103

Post by dualogy »

IronKettle wrote: post #3

This is totally an incomplete thought, and I'm not trying to be down on this author in particular: It's interesting to see a lot of management thoughts and colloquialisms slowly creep into the "other side" of software development (i.e. the actual developers) and become fairly well-tolerated. We still make fun of phrases like "paradigm" or "synergy", but we're all mostly on-board with phrases like "own " or "growth mi…

> You can see the author using the word "leverage" here repeatedly

Or maybe devs/engineers are just growing more eloquent than used to be? "Leverage" is truly the most intrinsic essence of everything engineering/developing. Reducing man-days, eliminating manual efforts, extracting infinitely reusable abstractions, code that emits+evals code .. I could go on and on and on --- hard to find a more sufficiently terse umbrella moniker that captures the mindset behind it all than "leverage"!

Re: Effective Engineer – Notes

#104

Post by avprpl »

DoreenMichele wrote: post #91
edmondlau wrote: post #16

Earlier quoted context omitted.

It's less about management and technical ability, and more about soft skills and hard skills. A recent Washington Post article shared an analytical study from Google on what made engineers at the company successful: "Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Goog…

among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. I have a lot of those soft skills. But no one is going to hire me as an engineer because I don't have the coding skills. It comes in dead last because you have to have high level coding skills to get your foot in the door. Everyone has that. Getting ahead in that crowd means having others assets on top of being a go…

I agree. If everyone at some company meets some bar for expertise, then differentiation among peers comes elsewhere.

Re: Effective Engineer – Notes

#105

Post by rifung »

brucephillips wrote: post #83
robotsonic wrote: post #36

Earlier quoted context omitted.

>Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. This result seems a bit unsurprising. People who work at Google would already be in the top n-th percent in terms of STEM expertise. If everyone you hire is 'above average' then being a bit better than that has marginal gains and other factors would lead to your s…

Another likely bias is that success is probably measured by peer review, and peers are more likely to overvalue soft skills.

Is there any evidence this is happening? I work at Google and as a lower level engineer more often than not wish some of the leads had better soft skills which makes me think they're not emphasized nearly enough in terms of promotion, which is at least one measure of success.

I believe promotion committees try to see measurable impact, which at least to me sounds like soft skills unfortunately don't help much..

Re: Effective Engineer – Notes

#106

Post by nostrademons »

"Opportunity cost of working on wrong ideas can set back growth by years."

I feel like this is spoken by someone who hasn't seen more than one technology cycle come and go.

What I've observed - having started my career back in the Java-will-eat-the-desktop days and then adapted through webapps, big data, mobile, and now AI - is that the people who are best positioned to capitalize on an emerging technology wave are the ones who started working on it before anyone realized it was important, just because it was interesting to them. They're the ones who write the papers and software that everyone else evangelizes, and then get multi-million-$ signing bonuses or stock grants (or billions of dollars worth of cryptocurrency) when corporate interests catch on that this is a new technology wave. But at the time they start working on the idea, it's both useless and unlikely to work.

You can make a decent living always being on the look out for a new technology wave and jumping on it as soon as it's clear that it's hot. I spent much of my 20s doing that, and made enough money doing so that I can take it a bit easier now. But it's exhausting, and you'll never be the one actually driving change.

It's also usually not clear what's the "wrong idea" except in retrospect. DropBox is rsync with cloud storage and some pretty slick desktop app integration, done at a time when everybody thought that desktop apps were dead and Drew's Windows hacking skills were old news. But it's that familiarity with old technology that put him in a place to realize that new technology could make the old technology dramatically more useful, to the tune of a $10B company.

Re: Effective Engineer – Notes

#107

Post by brucephillips »

nostrademons wrote: post #106

"Opportunity cost of working on wrong ideas can set back growth by years." I feel like this is spoken by someone who hasn't seen more than one technology cycle come and go. What I've observed - having started my career back in the Java-will-eat-the-desktop days and then adapted through webapps, big data, mobile, and now AI - is that the people who are best positioned to capitalize on an emerging technology wave are t…

"useless and unlikely to work" -/-> wrong

Re: Effective Engineer – Notes

#109

Post by edmondlau »

brucephillips wrote: post #97
edmondlau wrote: post #95

Earlier quoted context omitted.

Yep! I've read The Effective Executive. One of my big motivators for writing the book was that there were all these great ideas that were encapsulated in business books or personal improvement books, and very few books that would tie them back to engineering. That's the gap I wanted to fill.

Great. Though one of the complaints I have here is the same I have with Drucker, and the same that others have given: "Impact" is ill defined.

Your observation is a key reason why taking the time to define your impact and to measure it is so important. As Drucker says, what gets measured gets improved.

In business contexts, your engineering impact generally ties back to the business value you create (i.e. revenue and profit). If there is already some model for translating your area of work to revenue (e.g. increase users -> increase revenue, reduce fraud -> increase revenue) then that can also give another proxy metric to optimize for. So for example, when working on Google Search Quality, we would often just optimize for long clickthrough rates, knowing that strategically, the ads team would take care of turning returning searchers to revenue.

It gets harder when you're working on areas like bigger bets (where you can have high impact but it is unknown for a long time) or in trying to understand an infrastructure investment in terms of its business value to the company. There, it may be sufficient to just know that something is of strategic value and then measure your impact in terms of those strategic goals.

Post reply on HN