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

211–220 of 236 posts

Re: Effective Engineer – Notes

#211

Post by valuearb »

yanilkr wrote: post #209
valuearb wrote: post #203

Earlier quoted context omitted.

Wow. The author really pissed your cornflakes, didn’t he? I’ve been an engineer for 30 years, this is the first i’ve heard of author or his book, but i have to say i agree with much of his advice. When you have a choice, you should always choose high leverage. You should work to limit distractions and get more focus time. This is all great advice.

I see what you are trying to do here. But please go read the sales copy of the book. Everything in that copy is a symptom of "moral decay" in the tech valley. Which one did you purchase? "The master package" to become effective engineer. It makes bold claims like it will make you 10X engineer and it some how guides you to figure out which technologies you need to work that will succeed in the future and keep reading,…

I haven’t paid the author a dime, but did just sign up to get the free chapter of the book, i recommend you read it because it’s his actual advice. My review was it’s pretty good, a bit rushed/compressed, but his advice is very straightforward and all focused on getting more and better work done for your company, how much more team oriented does it get than that?

BTW i didn’t see any marketing claim on his site that he’ll magically turn you into a 10x developer, but googling found this blog. Read it and try to tell me it’s advice isn’t good or that it’s “corrosive” in any way to the team.

http://www.effectiveengineer.com/blog/how-to-become-a-10x-en...

Re: Effective Engineer – Notes

#212

Post by nostrademons »

pjc50 wrote: post #200
nostrademons wrote: post #130

Earlier quoted context omitted.

That's true and part of the challenge. It's not always clear what's a powerful technology wave and what's the wrong one. I've actually got a bit more of a personal connection to DropBox - Drew was active on HN before founding it, he posted it here before posting it on Digg [1], and he took me out to lunch right after they'd gotten their Sequoia seed round and asked if he could convince me to be employee #2. At the ti…

> it takes a certain amount of chutzpah to hear about all these eminent people saying "This will be the next hot thing, you better get in now!" Really? If you don't have that filter you'll be prey for every investment scam that comes along.

Many people are.

Re: Effective Engineer – Notes

#213

Post by davidjnelson »

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?

How about revenue or moving the needle on a key business metric like churn or order flow conversion rate.

Re: Effective Engineer – Notes

#214

Post by davidjnelson »

nine_k wrote: post #161
jyriand wrote: post #159

It's strange how obsessed software engineers are about methods of working. At a surface level it's just: sit down and write the code. But actually there are thousands of programming languages you can choose from; there are build tools, code standards, testing(to TDD or not to TDD) and mental models you have to wrap your head around before you even can start to consider yourself a decent programmer. It's fascinating,…

If it was simpler, it wont command such wages, and would be automated out sooner. Humans' current advantage is the ability to tackle complexity and uncertainty.

Another way to look at it is automation will free people up to solve more important problems.

Re: Effective Engineer – Notes

#215

Post by davidjnelson »

edmondlau wrote: post #175
ashwinaj wrote: post #142

Earlier quoted context omitted.

Hi Edmond, your book was great and I enjoyed reading it! I do have a question on your topic on high leverage work; as a startup how would you know what is high leverage work? You have talked about various tooling projects at Quora which turned out to be duds, but how would you know that beforehand without trying? I guess the same applies to your book...

Awesome, I'm happy you enjoyed it! In some sense, it might actually be easier to tell at a startup because what matters at a startup is growth. That can be growth of revenue (if you already have a product to sell) or growth of users (if you need traffic first to sell, e.g. Quora). The highest-leverage work would then be the things that most directly lead to that growth. Sometimes, this will require talking with produ…

Any tips on getting buy in to things like this, where the CEO would be on board but middle management would not prioritize it?

Re: Effective Engineer – Notes

#216

Post by davidjnelson »

edmondlau wrote: post #23
mzzter wrote: 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…

What’s the right level of completion for validation? A few weeks for a prototype seems reasonable, but even that can result in feedback that isn’t or isn’t considered fast enough.

Re: Effective Engineer – Notes

#218

Post by brucephillips »

davidjnelson wrote: post #216
edmondlau wrote: post #23

Earlier quoted context omitted.

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…

What’s the right level of completion for validation? A few weeks for a prototype seems reasonable, but even that can result in feedback that isn’t or isn’t considered fast enough.

It depends. Easily communicated product ideas can be validated on day 0 by talking to users.

Less easily communicated ideas often need at least a demo. Dropbox is one example.

Re: Effective Engineer – Notes

#219

Post by jodrellblank »

High leverage, compounding learning, exponential growth, high impact work, high priority, fast paced, focus on value, larger time blocks, ever deeper flow, prioritization for higher leverage, faster deployment, faster tools, shorter iterations, skyrocketing productivity, scale impact beyond confines, impact scaling, time saving, shorter loops, faster tests, shorter compiles, mastered tools...

Does any of this seem a bit Shepard Tones to anyone else?

https://www.youtube.com/watch?v=OsBanpBQj0k

(ever-ascending-tones audio illusion)

Re: Effective Engineer – Notes

#220

Post by sethammons »

Blazespinnaker wrote: post #110

Lot of very selfish anti team ideas here. Shipping requires doing grunt work. That’s the person I want to work with and that’s the person I think is valuable.

Perhaps I misread the post. I thought there were several points about putting your team first.

I've found that this can mean doing grunt work or it can mean reducing siloed information by having them do grunt work. This is to say that helping the team, helping grow yourself, and helping to ship product are not mutually exclusive from each other.

Post reply on HN