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

1–10 of 236 posts

Re: Effective Engineer – Notes

#2

Post by inetknght »

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

Re: Effective Engineer – Notes

#3

Post by IronKettle »

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 mindset". You can see the author using the word "leverage" here repeatedly in the same way that we often chide managers for using words like "synergy".

Interestingly the conversation around "effective engineers" has also shifted to really de-emphasize that technical ability - the best engineer is a good teammate, first and foremost (and I think a not-so-subtle implication also is that a good engineer is mostly extroverted as well). In the past decade or so, it seems like the "effective engineer" has become one who straddles that line between management and technical ability.

I don't really have an opinion on this yet (I think there's good and bad, as with most things), but it's just fascinating to watch.

Re: Effective Engineer – Notes

#4

Post by yanilkr »

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

Re: Effective Engineer – Notes

#5

Post by eitland »

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.

Re: Effective Engineer – Notes

#6

Post by whistlerbrk »

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.

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.

Re: Effective Engineer – Notes

#8

Post by pm90 »

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 good teammate: I don't think it is about extroversion as much as realizing that modern software systems are very non-monolithic and thus require cooperation among many different services to work effectively. This means that the days when a person could write the entire thing by himself/herself is over, and a lot more co-operation is required among engineers to design and build effective systems. 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.

Post reply on HN