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

41–50 of 236 posts

Re: Effective Engineer – Notes

#41

Post by IronKettle »

pm90 wrote: post #8
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 think you're being a little too pessimistic, although I do see where you're coming from. Technical jargon and vocabulary aren't created out of thin air: they are meant to efficiently and effectively convey certain facts and behaviors. Sometimes (perhaps many times?) there are co-opted and misused by certain people (many times managers, since they're further away from actual coding). The thing about engineer being a…

> That cooperation requires a certain amount of communication skills (apart from stellar technical skills), but it doesn't mean that you have to be an extrovert.

Yeah, and I realize it's a spectrum and not a binary thing. My point was more:

If we use the simplistic, trendy definition of introversion/extroversion as "do you gain energy having conversations or does it require energy?" and then say that regular conversations are an extremely important part of doing modern development work, I think it's fair to say that you're implicitly selecting for extroverts.

And again, I don't really put a judgement on that. I think it's fair to say "regular conversations are required to be successful as a software developer." I'm just noting the shift (as you've also done!).

Re: Effective Engineer – Notes

#42

Post by edmondlau »

apthnz wrote: post #29

On the "read code written by brilliant engineers" point, as someone just starting to learn Python, where would I find some?

If there are engineers you highly respect on your team, their code is a great place to start.

Otherwise, many top tech companies now open source software that they've written internally, oftentimes with their own websites. And there is also a growing trend for them to actually maintain the software they open source as opposed to just throwing it over the fence.

Think of companies that have a strong engineering brand, and then just search for what open source software they're released. Pick whatever seems most aligned with your interests.

Some examples:

Google: https://opensource.google.com/projects/list/featured?languag... Facebook: https://code.facebook.com/projects/#backend Stripe: https://stripe.com/open-source Airbnb: http://airbnb.io/projects/

Re: Effective Engineer – Notes

#43

Post by lazyasciiart »

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?

Re: Effective Engineer – Notes

#44

Post by quadcore »

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 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 for an individual to be successful in a group of men. I think Im safe in saying this is like that since the dawn of men. Specifically here, it happens in organisations big enough so that people's actual productivity is unknown.

Innovation though generally doesn't happen in such environment.

Re: Effective Engineer – Notes

#46

Post by anichale »

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…

> coding styles enforced: bad changes to good code no longer stick out like a sore thumb!

I can see the benefit of being able to identify smelly code immediately from poor code structure. However, I think that coding styles enforce consistency between good programmers who maintain their own coding style. A reviewer should be able to discern code quality - even with compliant code style - by how quickly it is to comprehend.

Re: Effective Engineer – Notes

#47

Post by IronKettle »

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

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 really topics that should be addressed much, much earlier (empathy in particular is something we should start teaching children as young as possible) and should be mature ideas by the time people reach college-age.

> The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.

To mirror the other comment, I hate to say it but if you're a software engineer at Google you're likely already a "top" engineer.

You're trying to explain what differentiates the top 0.1% from the top 1%, but I'm not sure it's a super useful distinction for the other 99%. For them, investment in hard skills might actually be considerably more fruitful (and land them that Google job in the first place).

Maybe not, I'll admit I could easily be wrong on that.

Re: Effective Engineer – Notes

#48

Post by edmondlau »

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…

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 coaching and listening skills can have a transformative impact on participants.

If you're interested in future workshops, you can sign up to hear about them here: https://effectiveengineer.typeform.com/to/cDMeZu

Re: Effective Engineer – Notes

#49

Post by fernandopj »

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…

I strongly agree with this analysis. It's already a population with strong STEM abilities, it should suffer from some sort of diminishing returns after an already high hiring standard on a company well-known for hiring only top students.

It's like conducting an analysis on skills of all F-1 drivers, and what differentiates champions from remaining pilots. I'd expect a lot of mindset-related and soft skills to appear as key indicators, and "driving abilities" to have a minimal gap between drivers.

Re: Effective Engineer – Notes

#50

Post by Terr_ »

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…

The effect can't last long though: The long-surviving codebase becomes such a mix of styles that it's more noise than signal, and even the good code appears as just another local inconsistency.
Post reply on HN