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

71–80 of 236 posts

Re: Effective Engineer – Notes

#71

Post by goialoq »

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…

Many adults have an aversion to new words. Foods too! Over time, they grow accustomed.

Re: Effective Engineer – Notes

#72

Post by goialoq »

eitland wrote: post #5
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”.

Also it comes off as a way to build a career at the companys expense.

Which parts hurt the company?

Re: Effective Engineer – Notes

#73

Post by beager »

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…

Somewhat unrelated, it would be great to have a Medium-style highlight feature for codebases, where you could onboard developers toward excellent practice by highlighting good code in a repository that consists of various levels of code.

Re: Effective Engineer – Notes

#74

Post by ralmeida »

halter73 wrote: post #69
barrkel wrote: post #58

Earlier quoted context omitted.

"Leverage" has real meaning. Another word for it that you might be more familiar with from software is "reuse". Reuse is leverage. If a piece of software (function, class, module, service, tool, whatever) is used for 1 task, it's not leveraged. If it's used for 10 tasks, that means the creation of the reused thing had 10x leverage: working on that reused thing created 10 times more value than working on something tha…

What's your point? Synergy has real meaning as well. The problem is when concepts like leverage or synergy become goals in and of themselves. That might be something you'd expect from someone who's read a lot of management books, but you'd expect engineers to see these as means to an end.

While I don’t advocate the use of these terms in every situation, it’s hard to have all ends in mind and to carefully choose which tool should be applied to each end. That may be why these properties are used as goals. Easier to spot, easier to reason about. Basically, they are heuristics.

Re: Effective Engineer – Notes

#75

Post by marcosdumay »

edmondlau wrote: post #16
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…

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 prase "success of people working at X is correlated with Y" has about the same meaning of "X recruitment process is weakest on select Y".

Re: Effective Engineer – Notes

#76

Post by bsder »

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

Re: Effective Engineer – Notes

#77

Post by sbov »

kbenson wrote: post #52
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…

> Unfortunately, almost all computer science education nowadays focuses on pure technical skills Assuming by computer science education you mean the actual classes within that major, I don't see this as a problem. I didn't take CS classes to learn interpersonal relationship skills. Other college classes and the college experience in general does help with that though. If talking about tech programs, I also think that…

Our CS program had a "basic communication" class, where you learned to write basic reports, memos, emails, your resume, etc. The final project was investigating some piece of tech, writing a 30 page paper on it, and presenting your findings to the class. Other CS teachers were invited to drop in during the presentations too.

Supposedly they added this after receiving feedback from industry that the biggest problem was that their graduating students couldn't properly communicate.

Altogether it felt pretty appropriate, since it was still focused on CS related concepts.

Re: Effective Engineer – Notes

#78

Post by Waterluvian »

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…

I'm first in line to make fun of the title "scrum master" and other nonsense. But the things that have crept in seem to have because they work.

I'm results driven. I don't care who comes up with what or what it's named. If it works, I'm on board. If it doesn't, I'll lambast it.

Re: Effective Engineer – Notes

#79

Post by ssivark »

edmondlau wrote: post #16
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…

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…

> Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last.

And yet it seems to me that the typical software/technical interview process emphasizes #8 more than the other seven. Maybe like the drunkard searching for lost keys under the lamp post. Quite sobering.

Re: Effective Engineer – Notes

#80

Post by joshuamorton »

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.
Post reply on HN