YetanotherHackerNewsdigest.com
HN Theater | HN Academy | HN Books

HN Books @HNBooksMonth

The best books of Hacker News.
Rankings: week · month (mar/apr) · year (2024) · all time
digests · search

Hacker News Comments on
The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact

Edmond Lau, Bret Taylor · 6 HN comments
HN Books has aggregated all Hacker News stories and comments that mention "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact" by Edmond Lau, Bret Taylor.
View on Amazon [↗]
HN Books may receive an affiliate commission when you make purchases on sites after clicking through links on this page.
Amazon Summary
The most effective engineers — the ones who have risen to become distinguished engineers and leaders at their companies — can produce 10 times the impact of other engineers, but they're not working 10 times the hours. They've internalized a mindset that took me years of trial and error to figure out. I'm going to share that mindset with you — along with hundreds of actionable techniques and proven habits — so you can shortcut those years. Introducing The Effective Engineer — the only book designed specifically for today's software engineers, based on extensive interviews with engineering leaders at top tech companies, and packed with hundreds of techniques to accelerate your career. For two years, I embarked on a quest seeking an answer to one question: How do the most effective engineers make their efforts, their teams, and their careers more successful? I interviewed and collected stories from engineering VPs, directors, managers, and other leaders at today's top software companies: established, household names like Google, Facebook, Twitter, and LinkedIn; rapidly growing mid-sized companies like Dropbox, Square, Box, Airbnb, and Etsy; and startups like Reddit, Stripe, Instagram, and Lyft. These leaders shared stories about the most valuable insights they've learned and the most common and costly mistakes that they've seen engineers — sometimes themselves — make. This is just a small sampling of the hard questions I posed to them: What engineering qualities correlate with future success? What have you done that has paid off the highest returns? What separates the most effective engineers you've worked with from everyone else? What's the most valuable lesson your team has learned in the past year? What advice do you give to new engineers on your team? Everyone's story is different, but many of the lessons share common themes. You'll get to hear stories like: How did Instagram's team of 5 engineers build and support a service that grew to over 40 million users by the time the company was acquired? How and why did Quora deploy code to production 40 to 50 times per day? How did the team behind Google Docs become the fastest acquisition to rewrite its software to run on Google's infrastructure? How does Etsy use continuous experimentation to design features that are guaranteed to increase revenue at launch? How did Facebook's small infrastructure team effectively operate thousands of database servers? How did Dropbox go from barely hiring any new engineers to nearly tripling its team size year-over-year? What's more, I've distilled their stories into actionable habits and lessons that you can follow step-by-step to make your career and your team more successful. The skills used by effective engineers are all learnable. And I'll teach them to you. With The Effective Engineer, I'll teach you a unifying framework called leverage — the value produced per unit of time invested — that you can use to identify the activities that produce disproportionate results. Here's a sneak peek at some of the lessons you'll learn. You'll learn how to: Prioritize the right projects and tasks to increase your impact. Earn more leeway from your peers and managers on your projects. Spend less time maintaining and fixing software and more time building and shipping new features. Produce more accurate software estimates. Validate your ideas cheaply to reduce wasted work. Navigate organizational and people-related bottlenecks. Find the appropriate level of code reviews, testing, abstraction, and technical debt to balance speed and quality. Shorten your debugging workflow to increase your iteration speed. Use metrics to quantify your impact and consistently make progress.
HN Books Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this book.
Anything about leverage. Here are the ones I read that were helpful. The second two are engineering-specific, but Principles is domain agnostic.

* Principles: https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/150...

* The Effective Engineer: https://www.amazon.com/Effective-Engineer-Engineering-Dispro...

* High Output Management: https://www.amazon.com/High-Output-Management-Andrew-Grove/d...

⬐ cmonaghan
+100 to The Effective Engineer. This is the best practical book on how to improve individual engineering effectiveness that I've ever read.
I think this book would be great addition to any software engineer . I think book captured the recent modern practices ( last 10 years?) in one place .

The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact

Effective Engineer - Notes : https://gist.github.com/rondy/af1dee1d28c02e9a225ae55da2674a...

https://www.amazon.com/Effective-Engineer-Engineering-Dispro...

The Effective Engineer[0] has a chapter on technical debt, where he goes into how a lot of crappy code decisions are there for a reason, and how rewrites can be chaotic. If you have the time, I'd recommend giving it a read.

I frankly got a lot more pragmatic about asking for rewrites after reading it, and I feel it helped me to grow (mature?) as a developer.

Either way, I think there's a need to balance the need for employee self actualization needs which they often push as rewrite requests "Oh since we're rewriting this, we should (do it in)/use/etc X instead". I have often realized that a lot of requests to rewrite something are really tinkering desires camouflaged as a business related request, which is not to say that the code that does exist could have problems, it could, but having a period of debt repayment would improve it as well. So finding a way to allow your employees to tinker without letting their desires torpedo your products would be positive.

Either way, it's a complex subject, and I don't really think there's a single "right" response to it. Best of luck!

0: https://www.amazon.com/Effective-Engineer-Engineering-Dispro...

EDIT: I'm not a CTO, I'm a developer.

I really liked "The Effective Engineer" by Edmond Lau. Its not intended for starting your own company. But it has some good insight for doing good in your job and how to grow as a software engineer. https://www.amazon.com/Effective-Engineer-Engineering-Dispro...
⬐ None
None
A relatively new book that isn't mentioned (but that I really like) is "The Effective Engineer" by Edmond Lau.

https://www.amazon.com/Effective-Engineer-Engineering-Dispro...

Edit: Here's why I like it: https://henrikwarne.com/2017/01/15/book-review-the-effective...

⬐ tekoyaki
Currently reading this since I saw your blog post. Thanks!
Your comment reminded me of Edmond Lau's book - The Effective Engineer [1] - where he talks about putting in a good amount of effort into the onboarding process for new engineers.

His premise - having a senior engineer spend an hour a day for the first month helping the new employee with explaining the existing abstractions being used, the underlying design of various systems, etc. - would still be only about 20 hours, which is still only 1% of the number of hours that employee will spend in their first year - about 2000 hours.

As a result, I believe that armed with that knowledge, the new employee is likely to be much more productive, failing which, at least cause less damage to the code base.

I would say that the first example you mention - leaky abstractions et. al. - are just as much (or maybe more) due to poor onboarding as they are due to the frustration of mediocre programmers. There is a lot to be said for good process, which software engineering as a discipline falls short of quite consistently.

[1] https://www.amazon.com/Effective-Engineer-Engineering-Dispro...

⬐ agentultra
Agreed!

I would wager that 90% of good software (by a most liberal definition) is designed to be that way by the methods employed to construct it. It's the leaders and managers who set those processes and standards. If they are well versed in the state of the art and understand how to make it work for the business you can end up with crystalline entity software. Most of my job is presently "hacking the process" rather than the code itself so that the team can produce the best, desirable results.

I'll check out that book, thanks for the recommendation.

HN Books is an independent project and is not operated by Y Combinator or Amazon.com.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.