Hi! I'm Edmond, the author of the book. Happy to answer any questions about my two-year journey in self-publishing the book.
Effective Engineer – Notes
11–20 of 236 posts
Re: Effective Engineer – Notes
#12This 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.
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.
Re: Effective Engineer – Notes
#13Re: Effective Engineer – Notes
#14Hi! I'm Edmond, the author of the book. Happy to answer any questions about my two-year journey in self-publishing the book.
What was the process like? How much time did you spend relative to other projects, and how did you incorporate your principles of leverage into creating the book?
Re: Effective Engineer – Notes
#15This 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…
This is a mindset that I encountered a lot from managers and VPs at Google. The premise is that the best way to improve one's incremental technical contribution is to improve an entire team.
If you bust your ass for a year and improve your own technical chops, you might be able to implement stuff 10% faster. Instead, you could help a team of 30 people to produce 10% more work. This is achievable from my anecdotal experience, but citation needed. At this point, you can throw your 10% incremental improvement out the window because now your incremental engineering improvement is 10% of a 30 person team, or 3 engineers. Now imagine you organized a department of 300 engineers to develop the right mix of infrastructure, forward-looking projects, and core projects such that the organization runs and grows efficiently. Now your incremental technical contribution is so much larger than the initial 10% that it's laughable.
This doesn't have to be limited to management, which is where I think the Google VP perspective falls a little flat. You can do this kind of work through pure technical contributions. I think managers write about this kind of leverage more often, but it can come from any kind of organization. A core library or tool has a massive impact, because it's reusable past the bounds of your team. Maybe you're change isn't 10% distributed across 30 people, but you could improve 3000 people by 1%.
Re: Effective Engineer – Notes
#16This 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 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."
Unfortunately, almost all computer science education nowadays focuses on pure technical skills and hiring interviews at most tech companies also focus on the technical skills. 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.
Here's the article: https://www.washingtonpost.com/news/answer-sheet/wp/2017/12/...
Re: Effective Engineer – Notes
#17Hi! I'm Edmond, the author of the book. Happy to answer any questions about my two-year journey in self-publishing the book.
I saw your google tech talk a while ago, and I really like the concept of leverage even though I usually dislike this genre
https://www.youtube.com/watch?v=BnIz7H5ruy0 I think people get too religious about effectiveness.
I was wondering what you do when you don't want to follow a list of good things to do? I assume self-publishing was discouraging at times, wasn't it?
Re: Effective Engineer – Notes
#18Earlier quoted context omitted.
Also it comes off as a way to build a career at the companys expense.
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.
Re: Effective Engineer – Notes
#19Hi! 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.
Re: Effective Engineer – Notes
#20> 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.
> ... If one party's not on board, then it's going to end up being a problem.
Idealism, IMHO, acts as a motivator and helps folks get through the obstacles that inevitably block progress.