Live data from Hacker News

Effective Engineer – Notes

gist.github.com

81–90 of 236 posts

Re: Effective Engineer – Notes

#81

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.

>But the things that have crept in seem to have because they work.

Keep in mind that things like Agile and Scrum might have had buy-in from team members because a team member adopting it wasn't as high of a cost as the same team member leaving the job. You might be able to object, but you'll probably be overridden.

There's some amount of reprogramming that happens there to keep the team cohesive, so people might begrudgingly adopt new habits. So in those cases, "it works" is barely sneaking in because everyone was forced to make it work.

It's not as easy to prove/disprove as more objective things like program performance, size, or correctness. There's a whole lot of flavors of "it works" out there.

Re: Effective Engineer – Notes

#82

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…

What about this is specific to men?

Re: Effective Engineer – Notes

#83

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…

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

Re: Effective Engineer – Notes

#84

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…

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?

Re: Effective Engineer – Notes

#86
post #56

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.

"Synergy" is a precise term as well.

Re: Effective Engineer – Notes

#88

> Optimize for Learning An idealist, for sure... > Prioritize learning over profitability. ... but that doesn't sound very pragmatic. I love learning. My boss loves making the company profitable. Coming to a happy medium is where a lot of learning can happen if both of you let it. If one party's not on board, then it's going to end up being a problem.

> Prioritize learning over profitability. This is idiotic advice. You can learn in big "boring" corps just like you can in hot startups but at the end of the day a job is about money.

> ... at the end of the day a job is about money.

This is short-sighted. A job is what you make of it - you can get lots of different things out of it. Otherwise pro-bono work, internships, etc. couldn't exist. If all you're in it for is the paycheque in 2 weeks time, then that's all you're likely to get out of it.

When you look at a career as a whole - from both sides of the relationship - then it is beneficial for both you, and your employer, for you to increase the value that you provide to your employer. That can mean learning more so that you can be more efficient, do more (volume), do more (variety), do higher valued things (ie. via promotion).

Also, you're not wrong that you can learn in a big 'boring' corp but the conditions have to be right for it to happen, and those conditions are often more prevalent in companies that have knowledge or skills gaps - which is more often the case in smaller organizations (doesn't have to be a startup, could be a historically-under-funded/under-recruited IT group in a well-established corp).

Re: Effective Engineer – Notes

#90

> Optimize for Learning An idealist, for sure... > Prioritize learning over profitability. ... but that doesn't sound very pragmatic. I love learning. My boss loves making the company profitable. Coming to a happy medium is where a lot of learning can happen if both of you let it. If one party's not on board, then it's going to end up being a problem.

I really liked this post, and I'm again saddened to see 'take downs' in the comments (not solely addressing you). The author said "prioritize" not to sacrifice profitability in order to learn. By prioritizing learning you may very well increase profitability over the long term. See the recent Google Maps is a moat post.

Challenging an idea is not a "take down".
Post reply on HN