Live data from Hacker News

Effective Engineer – Notes

gist.github.com

91–100 of 236 posts

Re: Effective Engineer – Notes

#91

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…

among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last.

I have a lot of those soft skills. But no one is going to hire me as an engineer because I don't have the coding skills.

It comes in dead last because you have to have high level coding skills to get your foot in the door. Everyone has that. Getting ahead in that crowd means having others assets on top of being a good coder.

It is a little like saying "Height doesn't matter for success as a basketball player. As long as you are at least 6'6", what matters are these other attributes." Yeah, sure, cool. It isn't a strong differentiator for the in crowd because you can't even join the crowd without it.

Re: Effective Engineer – Notes

#92
post #19

Earlier quoted context omitted.

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.

Yes, "high-leverage" is a phrase I use in the book. I learned about leverage when I read Andy Grove's High Output Management. Why the word leverage? Time is our most limited resource. And so the way to really increase our impact (say by 10x) is not to increase the number of hours you work, but to increase your rate of impact, which is how I define leverage in the book. Another way to think about leverage is in terms…

Thanks for your response, I understand it better now. Sorry for what must have seemed like a stupid question.

Re: Effective Engineer – Notes

#93

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

Please don't insult.

Re: Effective Engineer – Notes

#94

Pretty good overview, although I was aghast when I saw that The Mythical Man Month was missing from the book list. The Effective Executive is also a timeless classic that's useful to anyone who manages anything.

It references the primary concept, and it also looks like much of the information from MMM is already distilled into this - which is not hard to do; MMM is a bit verbose if I recall correctly.

Re: Effective Engineer – Notes

#95

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

Have you read much Drucker? You cover some of the same ideas.

Yep! I've read The Effective Executive. One of my big motivators for writing the book was that there were all these great ideas that were encapsulated in business books or personal improvement books, and very few books that would tie them back to engineering. That's the gap I wanted to fill.

Re: Effective Engineer – Notes

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

Perhaps rather than spew vacuous insults, you could describe specifically how effective engineers differ from the descriptions in this post.

Re: Effective Engineer – Notes

#97

Earlier quoted context omitted.

Have you read much Drucker? You cover some of the same ideas.

Yep! I've read The Effective Executive. One of my big motivators for writing the book was that there were all these great ideas that were encapsulated in business books or personal improvement books, and very few books that would tie them back to engineering. That's the gap I wanted to fill.

Great. Though one of the complaints I have here is the same I have with Drucker, and the same that others have given: "Impact" is ill defined.

Re: Effective Engineer – Notes

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

What do effective engineers do then?

Re: Effective Engineer – Notes

#99

Does this violate copyright? It appears to be a clear derivative work. I ask because this is something I'd love to see more of, but I'd be afraid of doing myself because I don't want to get a C&D.

Is a book review a derivative work? The author of the book is in here politely answering questions rather than crying "you copied!" so the nice summary of his ideas must feel ok to him...

Re: Effective Engineer – Notes

#100

Earlier quoted context omitted.

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?

At Quip, we run one coding interview that happens on a laptop, and where your conversation and discussions with the interviewer, including how you handle suggestions and feedback, matter a huge deal.

For experienced hires, we'll do deep dives on technical projects that they've worked on. Sometimes, I'll frame these as "Suppose I'm a new member joining that team. Bring me up to speed." These interviews focus on whether the candidate can clearly articulate concepts, explain the big-picture motivations, defend decisions they've made, understand complex technical problems, and stay humble and share lessons learned.

For manager interviews, we'll also do interviews that are one-on-ones with engineers on actual issues that they're facing.

Post reply on HN