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

171–180 of 236 posts

Re: Effective Engineer – Notes

#171

Post by LrnByTeach »

jakevoytko wrote: post #15
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…

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 exp…

This Leverage concept can be applied to a family .

Instead of YOU, as head of household putting more hours to solve Home chores/issues, if you teach other 3 members of your family how to solve issues/do chores , you get 3X return .

An example is online shopping for Home: Instead of you spending time for all the research each time, teaching family members, you can achieve leverage .

> 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

Re: Effective Engineer – Notes

#174

Post by yks »

swanson wrote: post #137

My most useful insight/takeaway from the book was about leverage and what activities you choose to do as you progress in your career: in six months you could ship 1x engineers worth of output (or maybe 2x or 3x if you are really great) -- or you could help hire and onboard 10 engineers and create 10x worth of output. Thinking more strategically about the most effective way to spend my own time and energy was easily w…

you are pretty much saying that the most effective way to be an engineer is to not be one

Re: Effective Engineer – Notes

#175

Post by edmondlau »

ashwinaj wrote: post #142
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, 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 product managers or salespeople or users to understand what the biggest accelerators or roadblocks would be. So, for example, at Quip, I looked at data on how the product spread within teams and organizations, developed engagement metrics around it, and then built features to move those metrics.

Working on some projects that end up failing is perfectly normal. What's important is to front-load as much of the risk as possible and to be explicit about the hypotheses required to make a project successful so that you can validate them early and, if necessary, change course.

That's where some of the projects we worked on at Quora failed (e.g. topic groups, an infrastructure rewrite) -- we let ourselves be overly confident about what we knew and didn't invest the time to sanity check our hypotheses.

For my book, validation played a huge role. Even before I started writing my book, I had written engineering-related answers on Quora for over two years and started to get a sense of what resonated with readers. That helped me build confidence that there would be demand for something in this space. Continued feedback and reviews during the writing process built on that confidence more.

Re: Effective Engineer – Notes

#176

Post by sidcool »

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

Care to suggest better ways?

Re: Effective Engineer – Notes

#177

Post by Cursuviam »

andy_ppp wrote: post #152
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…

Wow awesome - I love this comment in particular: “For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.” CVS!!!

This is by far my favorite HN comment of all times.

Re: Effective Engineer – Notes

#178

Post by __strisk »

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?

Reading code is the equivalent of looking at solutions for math problems... is it more helpful reading the solutions without context or with? You need to see the original problem, and how the solution came about in response to that problem. In regard to this, I would say, pick a problem that has a solution (walkthrough, if possible) available and then attempt to solve it and then honestly check your solution against the given solution.

Re: Effective Engineer – Notes

#179

Post by yanilkr »

valuearb wrote: post #167
yanilkr wrote: post #147

Earlier quoted context omitted.

I will try to elaborate without trying to insult anyone. It might be harsh but I am sure the author can handle it. First of all look at this sales copy of the book. https://www.effectiveengineer.com/book It looks like a weight loss e-book product designed to trick ambitious people into impulse buying. It tries to build credibility by name dropping "google", "facebook", "insert big company here" every other paragraph.…

I'd say you don't seem to understand what makes an effective engineer. You ignore the benefits of introspection and discount the ability to improve yourself. Good habits can be cultivated. A career can be cultivated, any good engineer can target better jobs to move up step by step where they want to be. The author is just giving you advice for doing those things.

You may be right. Only the people who bought that “tactical toolkit” from that sales page are effective engineers. Everyone else may just not be up to it.

We used to call engineers who do tasks that elevate themselves at the expense of rest of the team as bad team players. Now the advice here is to do high leverage tasks.

The whole premise of the content appears to be a “get rich quick” scheme. The most vulnerable people in the industry are the young people looking for guidance and advice from older generations. The sales copy is clearly exploiting their insecurity by suggesting somehow there is a shortcut and by knowing these secrets for a small price, you too can be a 10x engineer.

Re: Effective Engineer – Notes

#180

Post by curun1r »

edmondlau wrote: post #100
brucephillips wrote: post #84

Earlier quoted context omitted.

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 whethe…

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

Be careful with this approach. If you're not paying candidates for their interview time, you're not allowed to use their work. Big companies go to great lengths to demonstrate that the entire interview is for the purpose of a hiring decision and nothing more. This is to limit liability. Your approach is very dangerous for your company and if an unhired candidate's idea shows up in your product, even if you arrived at that result independent of the interview, the candidate has a strong case against you in a lawsuit.

If you're doing interviews like this, be sure you've discussed all the nuances with your company's lawyers.

Post reply on HN