Effective Engineer – Notes • Hacker News Board

Re: Effective Engineer – Notes

#51

Post by mastratton3 » Thu, Dec 28, 2017, 7:08 PM UTC

robotsonic wrote: post #36

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…

>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…

This makes so much sense and frequently overlooked. I find even in other areas (such as sports), what makes someone seem really impressive generally isn't what is actually important.

A dumb example is from cycling, people frequently over-practice the ability to sprint at the end of a race but what is really important is the ability to conserve energy throughout the race... Really dumb example, but I think it is somewhat similar.

Re: Effective Engineer – Notes

#52

Post by kbenson » Thu, Dec 28, 2017, 7:08 PM UTC

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…

> 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 isn't necessarily something they can or should focus too much on, as that's not their focus. The assumption is you have that part already figured out. If not, go through a course that focuses on that in addition, I'm sure you'll get a better education in that topic that way. It probably is appropriate for them to stress it's important though, even if they don't offer much in the way of rectifying it.

Or, spend a lot of time on self-directed self improvement in one or both those areas. The resources and programs exist for that as well.

> and hiring interviews at most tech companies also focus on the technical skills.

I agree on this. Companies should hire people that will function within their system. Hiring the smartest guy from MIT's class of 2017 sounds all well and good, but if they can't function well with your existing 100 employees and they leave after a year or two (or worse, they cause a few other people at your company to leave every year causing high turnover), the chances of them somehow making up for that are probably extremely low.

Re: Effective Engineer – Notes

#53

Post by IronKettle » Thu, Dec 28, 2017, 7:10 PM UTC

lazyasciiart wrote: post #43

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…

As far as I'm aware, 'growth mindset' comes from education/psychology with Carol Dweck, not from management - did I miss something?

Not the first or the last time management has co-opted terms from academic fields :). Social psychology is especially ripe for this.

See also: "Paradigm shift" was coined by a physicist to talk about scientific revolutions, IIRC.

Re: Effective Engineer – Notes

#54

Post by [deleted] » Thu, Dec 28, 2017, 7:15 PM UTC

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…

[deleted]

Re: Effective Engineer – Notes

#55

Post by edmondlau » Thu, Dec 28, 2017, 7:15 PM UTC

IronKettle wrote: post #47

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 I'm not sure I'd really call that unfortunate. CS education isn't about making you a more well-rounded person: It's about giving you a basic education in Computer Science. Similarly I don't really lament that CS programs don't have a course in basic financial literacy, even though it would be incredibly useful. These are…

There's for sure a tricky balance on what fits into a CS education.

I remember when I was at MIT (oof, over a decade ago), many project-based CS courses where students were just put into teams and expected teamwork to just happen. Sometimes people got along, and the project would go fine. Other times, not so much.

I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair distribution of work. And back them, I ended up just avoiding them. Knowing what I know now, even a single lecture on tools for more effective teams or for having hard conversations or giving feedback would have made those projects SO much more valuable in terms of being learning experiences.

Given that effectively using your CS education will involve collaborating with other people to some degree, I do believe that giving more emphasis to the non-technical skills that play a big role in your career would have a hugely positive impact.

Re: Effective Engineer – Notes

#56

Post by guelo » Thu, Dec 28, 2017, 7:30 PM UTC

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 don't think so. Leverage has a precise concrete meaning in this article. We shouldn't avoid a descriptive accurate term just because it's for an abstract higher-order concept.

Re: Effective Engineer – Notes

#57

Post by IronKettle » Thu, Dec 28, 2017, 7:34 PM UTC

edmondlau wrote: post #55

IronKettle wrote: post #47

Earlier quoted context omitted.

> Unfortunately, almost all computer science education nowadays focuses on pure technical skills I'm not sure I'd really call that unfortunate. CS education isn't about making you a more well-rounded person: It's about giving you a basic education in Computer Science. Similarly I don't really lament that CS programs don't have a course in basic financial literacy, even though it would be incredibly useful. These are…

There's for sure a tricky balance on what fits into a CS education. I remember when I was at MIT (oof, over a decade ago), many project-based CS courses where students were just put into teams and expected teamwork to just happen. Sometimes people got along, and the project would go fine. Other times, not so much. I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair…

> I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair distribution of work.

I guess my point is more that primary school really should've prepared you for this: Group dynamics and how to handle these "group tensions" is more of a basic learning skill that we should be developing very early on.

I'm not arguing that this is a useless skill to teach, more that it's far more expensive and much less effective for MIT to be teaching you these skills and not MyTown elementary/middle/high school.

Re: Effective Engineer – Notes

#58

Post by barrkel » Thu, Dec 28, 2017, 7:36 PM UTC

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…

"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 that's only used once.

It's not quite that straightforward as everyone knows, there are costs to reuse (abstractions (both lowest common denominator and leakage), more dependencies, higher maintenance costs owing to risk of breakage of multiple clients, etc.). But the leverage is very often real.

Re: Effective Engineer – Notes

#59

Post by IronKettle » Thu, Dec 28, 2017, 7:37 PM UTC

guelo wrote: post #56

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 don't think so. Leverage has a precise concrete meaning in this article. We shouldn't avoid a descriptive accurate term just because it's for an abstract higher-order concept.

> Leverage has a precise concrete meaning in this article.

Er, not really. From the article:

> Leverage = Impact Produced / Time Invested

"Impact Produced" has a precise, concrete meaning?

Re: Effective Engineer – Notes

#60

Post by barrkel » Thu, Dec 28, 2017, 7:38 PM UTC

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…

This is the article that argues that for people in the top 1% of STEM expertise, STEM expertise isn't the distinguishing factor.

Frankly, it would be surprising if it was. If you've topped out that tech tree, most of your performance variance will come from other areas where there's more, uh, variance.