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

61–70 of 236 posts

Re: Effective Engineer – Notes

#61

Post by grandmczeb »

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…

I can’t speak to this particular study, but as a former Google employee, I would take any of the social “research” done at Google with a massive grain of salt. Very little is peer reviewed (or even externally available) and the stuff I looked at internally is not even remotely rigorous.

Additionally, the results that make it to the media get way exaggerated compared to the actual underlying study. This is compounded by the fact that Google picks and chooses what it publicizes, so what you’re seeing has a huge PR/political filter.

Re: Effective Engineer – Notes

#62

Post by barrkel »

IronKettle wrote: post #59
guelo wrote: post #56

Earlier quoted context omitted.

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?

Sure. For software, it might be reuse of a component. Reuse leverages existing code. This is precise, unambiguous, and frankly uncontroversial.

Re: Effective Engineer – Notes

#63

Post by wallflower »

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.

There are many people (including myself) who can operate quite successfully in the text-based world (Slack, email) and collaborate that way.

I think Slack (and other tools like it) helps the introvert be a more active participant or even a leader in certain technical discussions. Most especially, the ones where the servers are melting down.

Re: Effective Engineer – Notes

#64

Post by IronKettle »

barrkel wrote: post #62
IronKettle wrote: post #59

Earlier quoted context omitted.

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

Sure. For software, it might be reuse of a component. Reuse leverages existing code. This is precise, unambiguous, and frankly uncontroversial.

> it might be

> This is... unambiguous,

:)

Re: Effective Engineer – Notes

#65

Post by romanovcode »

inetknght wrote: post #2

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

Re: Effective Engineer – Notes

#66

Post by barrkel »

mzzter wrote: post #19
edmondlau wrote: post #11

Hi! I'm Edmond, the author of the book. Happy to answer any questions about my two-year journey in self-publishing the book.

Hi Edmond, is “high leverage” a phrase you use in the book? From the notes, “leverage” is defined as “impact / time invested.” Why did you choose “leverage” to describe this concept? “Leverage” suggests to me that it is grown with the idea of using it to climb a career ladder, but I’d like to hear your thoughts on this, as I have read just these notes and not the book yet.

Leverage directly implies multiplication. Leverage, the physical concept, multiplies force or torque (rotational force). The analogy applies finance: multiplying your profitable strategy with borrowings to multiply the gains. The analogy also applies in software: multiply the uses of your code to increase the value it creates.

Re: Effective Engineer – Notes

#67

Post by IronKettle »

wallflower wrote: post #63
pm90 wrote: post #8

Earlier quoted context omitted.

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. There are many people (including myself) who can operate quite successfully in the text-based world (Slack, email) and collaborate that way. I think Slack (and other tools like it) helps the introvert be a more active participant or even a leader in certain…

That's very true! I wasn't really thinking about Slack/etc. when I made that statement. Excellent point.

Re: Effective Engineer – Notes

#68

Post by barrkel »

eitland wrote: post #18
ashwinaj wrote: post #12

Earlier quoted context omitted.

You're forgetting the fact that the company is also building it's "career" off your's too. Don't believe me? Any invention that you have created at your workplace (patents etc.) is always held by your company, not you.

That's the deal though isn't it? They pay me real money - I do real work for them.

You expend labour; they build capital. The capital you build produces returns long into the future, but you don't own any of that future income stream. Sooner or later, your sharpness and skills will decline, and your labour will be relatively worthless. The capital you helped build will continue to be valuable (presuming you did a good job).

It's a poor deal if you're in a competitive market where there's another schmuck willing to do your job for just as cheap as you do it. But if you have pricing power, you'd be a complete fool not to either charge substantially more, or demand some ownership.

Re: Effective Engineer – Notes

#69

Post by halter73 »

barrkel wrote: post #58
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 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.

Re: Effective Engineer – Notes

#70

Post by ianbicking »

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?

Peter Norvig has lots of expository code that embodies lots of good design.

I find I like to learn the flavor of different kinds of code, but practical codebases have so much stuff going on that it's not easy to find the distinctive part. It would be great to see more people do expository versions of familiar software and libraries.

Post reply on HN