What do you think?
Rate this book
The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact
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
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 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.
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
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 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.
227 pages, Kindle Edition
First published March 19, 2015
318 people are currently reading
5494 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 253 reviews
September 7, 2017
I'm feeling ambivalent about this book.
On one hand, it starts with a revolutionary premise ("ha ha", laughed I in French) that _maybe_ working 60 hours a week is not the best way of getting things done. This is by all means a positive premise, especially in the toxic context of Silly Valley. Then he goes through a lot of different ways how we can make sure our time is spent in the best possible way. That is all cool.
However, this premise of not over-working is really tentative. The author doesn't really have the guts to tell his peers to stick to a reasonable 40 (or less) hour weeks. Also, the rest of the advice is suitably most for somebody new to a software development career. I hardly got anything new out of this book.
Also, it bothered me how the author goes into a habit of name-dropping of big (and "successful" companies), not really going into the dangers of cargo-culting. It seems a bit like an ego trip for him ("when I worked in Google…", "one of the projects I did in Quora…", etc.) more than a useful advice to the reader. I'd wish to see less of "me" and "this well-known company X", but more of scientific studies and arguments to back up the ideas. There are more developers in Europe than in the US and Canada combined and we don't really relate to the whole SV experience.
That being said, if you have no idea what you're doing and how to direct your career, this book might help you make the most out of it. Just don't treat it as gospel, just one engineers journey through the crazy hamster wheels of Silly Valley.
On one hand, it starts with a revolutionary premise ("ha ha", laughed I in French) that _maybe_ working 60 hours a week is not the best way of getting things done. This is by all means a positive premise, especially in the toxic context of Silly Valley. Then he goes through a lot of different ways how we can make sure our time is spent in the best possible way. That is all cool.
However, this premise of not over-working is really tentative. The author doesn't really have the guts to tell his peers to stick to a reasonable 40 (or less) hour weeks. Also, the rest of the advice is suitably most for somebody new to a software development career. I hardly got anything new out of this book.
Also, it bothered me how the author goes into a habit of name-dropping of big (and "successful" companies), not really going into the dangers of cargo-culting. It seems a bit like an ego trip for him ("when I worked in Google…", "one of the projects I did in Quora…", etc.) more than a useful advice to the reader. I'd wish to see less of "me" and "this well-known company X", but more of scientific studies and arguments to back up the ideas. There are more developers in Europe than in the US and Canada combined and we don't really relate to the whole SV experience.
That being said, if you have no idea what you're doing and how to direct your career, this book might help you make the most out of it. Just don't treat it as gospel, just one engineers journey through the crazy hamster wheels of Silly Valley.
May 28, 2016
Disappointing read for me. The author should have specifically called out the intended audience for this book (strictly suitable only to a complete newbie software engineer). As a result I had to wade through the lazy writing (reads like a series of bullet points with a smattering of routinely cited works - every business/tech book is referenced here once every couple of lines, is that really necessary? This often came across as filler material). $35 for a book that reads like a collection of blog posts is obnoxious, in my opinion.
August 27, 2017
Give this one out to all of your new engineers. It's a great writeup of modern engineering practices and ideas.
Beware: This book might be easily dismissed by hardcore techies as too fluffy and not technical enough. For people embracing a more holistic view on engineering it's great though. Fits perfectly in line with Goldratts and Gene Kim's books.
Beware: This book might be easily dismissed by hardcore techies as too fluffy and not technical enough. For people embracing a more holistic view on engineering it's great though. Fits perfectly in line with Goldratts and Gene Kim's books.
February 15, 2018
I read this book with a friend from work during a time when both of us were feeling rather cynical. Nevertheless, I think there are good and useful ideas in here, especially in the first few chapters for the non-senior individual contributor perspective. The glowing quotes from engineering management are there because yes, it paints a good portrait of effective engineering work, that they would want to have on their teams.
As an individual, though, the main thing to question is the extent to which you personally will reap the benefits and be recognized for the impact you're having. Maybe pairing this book with some of the posts on office politics by Erik Dietrich, like http://www.daedtech.com/defining-the-... If you care about being rewarded and promoted, this book is missing information on promoting your work internally, managing up, getting sponsorship, etc.
============
notes:
Part 1: Adopt the right mindsets
ch1: Focus on High Leverage Activities
Leverage formula = Impact produced / time invested
Not covered:
* personal incentives and the time scale for leverage to pay off (what if you’re not around for when the long-term benefits show up?)
* your perception of what’s valuable and that of people with more power than you may be different, this is dangerous
* there’s likely to be some kind of difference between the real and the recognized impact of your work. Pits selfishness of advancing your status against your own integrity and pride in your work.
* ship a technical piece of work that you can then promote the shit out of
ch2: Optimize for learning
* growth rate varies not only by company, but also by team. Is it possible that you grow more slowly when working on a legacy product? Things move more slowly there, generally the stuff that people are excited about has already been done, or the exciting potential stuff is much harder. However, legacy product-supporting teams tend also to be the revenue-generating ones, which brings some job security.
* autonomy for choosing what to work on: autonomy requires trust from management in your judgment of what should be worked on.
* suggestion for studying core abstractions written by more tenured engineers: shouldn’t assume that just because it’s been around for awhile, that it’s necessarily good code or were the right abstractions. Can learn a lot from figuring out what and why of the tradeoffs made, for the problem being solved at the time.
* suggestion to be on a team with at least a few senior engineers, so you can learn from them—makes sense, but probably also don’t want it all be people more senior than you are—fewer leadership opportunities for yourself then. So would want to be on a team where you’re more in the middle.
* “Jump fearlessly into code you don’t know” — definitely something to ing I should continue working on
* there are many suggestions of specific things to learn, can’t do all of them! need to choose.
* mantra: “There’s a limited time that I am not going to understand this.”
write up POODR notes
* suggestion to pursue what you love outside work & outside coding—for me, sewing, cooking. Satisfy to successfully build tangible things. Interesting theory that success in disparate areas fuels generally applicable motivation to continue improving.
ch3: Prioritize regularly
* Ask yourself on a recurring basis: Is there something else I could be doing that’s higher leverage? Goal is *not* to establish total reordering of priorities, since you’d be going down farther than you’ll get to anyway, and your information at the time is always imperfect. Instead, goal is to continually shift your priorities towards the items that are highest leverage, with the most updated information you have about what the leverage of each item would be.
* maker’s schedule: half-day seems to be too long a time for me, often am not as productive during an entirely free afternoon as I would like to be. Somewhere in a 2.5-3hour block seems better. Knowing I’ll be interrupted by a mid-afternoon meeting gives more of a sense of urgency and focus.
* idea of fighting procrastination with if-then plans, to reduce the amount of “activation energy” needed to get started on a difficult taskasdf. Great term! Strategies like leaving a failing test, having small to-do list items seem to help. Build up momentum to “warm up” into working (how I still treat dealing with work email in the morning)
* Can write out all the pieces you think would be included, then prioritize after writing them out.
* his to-do list categorization seems quite rigorous, though I suppose I have similar categories in my Google Doc, just not labeled
ch6: Validate your ideas early and often
* seems like should phrase as "try to invalidate your decisions" rather than validate them, to truly adhere to scientific method
ch7: Improve your project estimation skills
* I like this idea of "Engineers create estimates, and managers and business leaders create targets...Project schedules slip because we allow the target to affect the estimate."
* from The Mythical Man-Month: Essays on Software Engineering: "When one hears of disastrous schedule slippage in a project, he imagines that a series of major calamities must have befallen it. Usually, however, the disaster is due to termites, not tornadoes."
* overoptimize for what you believe to be the main concerns
* think of estimates as probability distributions, not best-case scenarios
* over optimizer for what you believe to be the main concerns—not just buffer, and don’t need to have equal buffer for everything. improve estimates by knowing what you could just cut and not have to work on/estimate entirely
* still don’t get short-term reward as IC for doing incremental work for rewriting system
urge to be efficient by doing more at once—dangerous! be more ok throwing code/time away, wasting some time in short-term in order for longer-term efficiency
* you’re probably more behind schedule than you think — if you were wrong about earlier estimates, probably also wrong about later estimates. past is not a one-off, future likely not best-case scenario
specific reasons why rewrite projects are dangerous and difficult to estimate: with “second system” want to incorporate all this stuff from lessons learned, but goals are less clear and mutate
“undertime” as opposite of “overtime”—not necessarily burned out yet, but slower after more intense time
ch9: Minimize Operational Burden
* fail fast to connect cause to failure more closely, like shorter iteration loops
* automating steps for a process vs trying to model decision-making. definitely want to automate steps but harder when judgment for what to do is needed, so can choose not to avoid that as much
* how to design idempotent process? every step needs to be able to be undone, or know if you’ve already done so it could be re-done. probably helps to break procedures down into smaller steps.
* another benefit of idempotency + neat actual idea for better stability: run infrequently needed processes more frequently, to catch those errors and give ahead-of-time buffer
* better to handle failures well or prevent failures?
ch10: Invest in Your Team’s Growth:
* nice to see critique of 80hour+ week startup experiences without weakening with “oh i learned a lot at least”
* but thesis of chapter is what’s good for your team is good for you, but…skeptical of this. prisoner’s dilemma a bit—if enough people on team set this culture, then it works, but otherwise if not enough, better to look out for yourself
* approaching engineering when looking in a rearview mirror and as an engineering manager now
As an individual, though, the main thing to question is the extent to which you personally will reap the benefits and be recognized for the impact you're having. Maybe pairing this book with some of the posts on office politics by Erik Dietrich, like http://www.daedtech.com/defining-the-... If you care about being rewarded and promoted, this book is missing information on promoting your work internally, managing up, getting sponsorship, etc.
============
notes:
Part 1: Adopt the right mindsets
ch1: Focus on High Leverage Activities
Leverage formula = Impact produced / time invested
Not covered:
* personal incentives and the time scale for leverage to pay off (what if you’re not around for when the long-term benefits show up?)
* your perception of what’s valuable and that of people with more power than you may be different, this is dangerous
* there’s likely to be some kind of difference between the real and the recognized impact of your work. Pits selfishness of advancing your status against your own integrity and pride in your work.
* ship a technical piece of work that you can then promote the shit out of
ch2: Optimize for learning
* growth rate varies not only by company, but also by team. Is it possible that you grow more slowly when working on a legacy product? Things move more slowly there, generally the stuff that people are excited about has already been done, or the exciting potential stuff is much harder. However, legacy product-supporting teams tend also to be the revenue-generating ones, which brings some job security.
* autonomy for choosing what to work on: autonomy requires trust from management in your judgment of what should be worked on.
* suggestion for studying core abstractions written by more tenured engineers: shouldn’t assume that just because it’s been around for awhile, that it’s necessarily good code or were the right abstractions. Can learn a lot from figuring out what and why of the tradeoffs made, for the problem being solved at the time.
* suggestion to be on a team with at least a few senior engineers, so you can learn from them—makes sense, but probably also don’t want it all be people more senior than you are—fewer leadership opportunities for yourself then. So would want to be on a team where you’re more in the middle.
* “Jump fearlessly into code you don’t know” — definitely something to ing I should continue working on
* there are many suggestions of specific things to learn, can’t do all of them! need to choose.
* mantra: “There’s a limited time that I am not going to understand this.”
write up POODR notes
* suggestion to pursue what you love outside work & outside coding—for me, sewing, cooking. Satisfy to successfully build tangible things. Interesting theory that success in disparate areas fuels generally applicable motivation to continue improving.
ch3: Prioritize regularly
* Ask yourself on a recurring basis: Is there something else I could be doing that’s higher leverage? Goal is *not* to establish total reordering of priorities, since you’d be going down farther than you’ll get to anyway, and your information at the time is always imperfect. Instead, goal is to continually shift your priorities towards the items that are highest leverage, with the most updated information you have about what the leverage of each item would be.
* maker’s schedule: half-day seems to be too long a time for me, often am not as productive during an entirely free afternoon as I would like to be. Somewhere in a 2.5-3hour block seems better. Knowing I’ll be interrupted by a mid-afternoon meeting gives more of a sense of urgency and focus.
* idea of fighting procrastination with if-then plans, to reduce the amount of “activation energy” needed to get started on a difficult taskasdf. Great term! Strategies like leaving a failing test, having small to-do list items seem to help. Build up momentum to “warm up” into working (how I still treat dealing with work email in the morning)
* Can write out all the pieces you think would be included, then prioritize after writing them out.
* his to-do list categorization seems quite rigorous, though I suppose I have similar categories in my Google Doc, just not labeled
ch6: Validate your ideas early and often
* seems like should phrase as "try to invalidate your decisions" rather than validate them, to truly adhere to scientific method
ch7: Improve your project estimation skills
* I like this idea of "Engineers create estimates, and managers and business leaders create targets...Project schedules slip because we allow the target to affect the estimate."
* from The Mythical Man-Month: Essays on Software Engineering: "When one hears of disastrous schedule slippage in a project, he imagines that a series of major calamities must have befallen it. Usually, however, the disaster is due to termites, not tornadoes."
* overoptimize for what you believe to be the main concerns
* think of estimates as probability distributions, not best-case scenarios
* over optimizer for what you believe to be the main concerns—not just buffer, and don’t need to have equal buffer for everything. improve estimates by knowing what you could just cut and not have to work on/estimate entirely
* still don’t get short-term reward as IC for doing incremental work for rewriting system
urge to be efficient by doing more at once—dangerous! be more ok throwing code/time away, wasting some time in short-term in order for longer-term efficiency
* you’re probably more behind schedule than you think — if you were wrong about earlier estimates, probably also wrong about later estimates. past is not a one-off, future likely not best-case scenario
specific reasons why rewrite projects are dangerous and difficult to estimate: with “second system” want to incorporate all this stuff from lessons learned, but goals are less clear and mutate
“undertime” as opposite of “overtime”—not necessarily burned out yet, but slower after more intense time
ch9: Minimize Operational Burden
* fail fast to connect cause to failure more closely, like shorter iteration loops
* automating steps for a process vs trying to model decision-making. definitely want to automate steps but harder when judgment for what to do is needed, so can choose not to avoid that as much
* how to design idempotent process? every step needs to be able to be undone, or know if you’ve already done so it could be re-done. probably helps to break procedures down into smaller steps.
* another benefit of idempotency + neat actual idea for better stability: run infrequently needed processes more frequently, to catch those errors and give ahead-of-time buffer
* better to handle failures well or prevent failures?
ch10: Invest in Your Team’s Growth:
* nice to see critique of 80hour+ week startup experiences without weakening with “oh i learned a lot at least”
* but thesis of chapter is what’s good for your team is good for you, but…skeptical of this. prisoner’s dilemma a bit—if enough people on team set this culture, then it works, but otherwise if not enough, better to look out for yourself
* approaching engineering when looking in a rearview mirror and as an engineering manager now
December 27, 2016
Great book filled with career advice that I plan to take with me for a long time. I will probably find myself re-reading sections too. The author cites evidence for most everything he says, and can speak to all of the points made from personal experience. Five stars on content.
My only issue is that the writing style is a bit formulaic, i.e. introduce concept, cite personal experience, cite best practices at other companies. There is also a lot of repetition - some of the companies are re-introduced several times before going into their best practices ("Asana, a startup that builds a task and project management tool" or a variant is a common refrain). This may be helpful if you treat this book as a reference, which I plan to do, but tedious if you read it straight through, which is what I did. The first and last chapters also repeat a lot of material, so I think the book could stand to be shorter. Three stars on writing style.
All this said, it was an easy read and the advice is clear: focus on high-leverage activities - and that may not always mean what you think it means. I would recommend this book to any current or aspiring software engineer.
My only issue is that the writing style is a bit formulaic, i.e. introduce concept, cite personal experience, cite best practices at other companies. There is also a lot of repetition - some of the companies are re-introduced several times before going into their best practices ("Asana, a startup that builds a task and project management tool" or a variant is a common refrain). This may be helpful if you treat this book as a reference, which I plan to do, but tedious if you read it straight through, which is what I did. The first and last chapters also repeat a lot of material, so I think the book could stand to be shorter. Three stars on writing style.
All this said, it was an easy read and the advice is clear: focus on high-leverage activities - and that may not always mean what you think it means. I would recommend this book to any current or aspiring software engineer.
March 9, 2016
A few good pieces of advice here and there but could easily have been summed up in a blog post. Very autobiographical.
February 28, 2022
I liked this a lot in the beginning, but it got more and more repetitive and less useful.
I'd put this in the category of "just read a summary of the book and that's enough"
I'd put this in the category of "just read a summary of the book and that's enough"
July 3, 2016
Edmond Lau discusses techniques that can make both junior and senior engineers more effective in their work. This book focuses on software engineers but many of the principles outlined here can be applied to other engineering disciplines, professions, and life in general.
I think that every software engineer can benefit from reading this book. Emond Lau is a software engineer himself and shares many of the lessons he learned the hard way. I found it interesting to read about engineering practices at Quora, Instagram, and lots of other successful companies. In fact, Edmond Lau interviewed many senior software engineers at leading technology companies and presents his findings in this book.
The book is well written, the author summarizes the key takeaways conveniently at the end of each chapter and the central message becomes very clear: we should focus our precious time on high-leverage activities and always question complexity. As Steve Jobs famously said: "When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can oftentimes arrive at some very elegant and simple solutions. Most people just don't put in the time or energy to get there." We should always ask, "What is the simplest solution that can get the job done?".
I think that every software engineer can benefit from reading this book. Emond Lau is a software engineer himself and shares many of the lessons he learned the hard way. I found it interesting to read about engineering practices at Quora, Instagram, and lots of other successful companies. In fact, Edmond Lau interviewed many senior software engineers at leading technology companies and presents his findings in this book.
The book is well written, the author summarizes the key takeaways conveniently at the end of each chapter and the central message becomes very clear: we should focus our precious time on high-leverage activities and always question complexity. As Steve Jobs famously said: "When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can oftentimes arrive at some very elegant and simple solutions. Most people just don't put in the time or energy to get there." We should always ask, "What is the simplest solution that can get the job done?".
July 10, 2016
"Time is our most finite asset, and leverage—the value we produce per unit time—allows us to direct our time toward what matters most."
Buku bagus, sangat direkomendasikan utamanya untuk mereka yg berkecimpung dalam dunia IT. Lebih cocok lagi bagi mereka pelaku start-up.
Banyak tips dari Edmond Lau, sang penulis, terkait bagaimana kultur atau contoh manajemen di sebuah start-up agar mampu membentuk effective engineer di perusahaannya. Getting things done, learn quickly, and not wasting effort.
Edmond Lau juga banyak memberikan contoh bagaimana perusahaan-perusahaan di Silicon Valley dalam menerapkan sistem hiring, onboarding, dan mentoring rekrutmen baru, A/B testing, dan lain sebagainya, yang menurutnya penting dalam membentuk effective engineer tersebut.
Dia mengambil contoh dari pengalamannya saat bekerja di Ooyala, Google, Quora, dan Quip. Tak ketinggalan juga contoh dari narasumbernya yang berasal dari Facebook, Dropbox, Box, dan perusahaan Silicon Valley lainnya. Banyak insight yang bisa kita peroleh dari buku ini.
Buku bagus, sangat direkomendasikan utamanya untuk mereka yg berkecimpung dalam dunia IT. Lebih cocok lagi bagi mereka pelaku start-up.
Banyak tips dari Edmond Lau, sang penulis, terkait bagaimana kultur atau contoh manajemen di sebuah start-up agar mampu membentuk effective engineer di perusahaannya. Getting things done, learn quickly, and not wasting effort.
Edmond Lau juga banyak memberikan contoh bagaimana perusahaan-perusahaan di Silicon Valley dalam menerapkan sistem hiring, onboarding, dan mentoring rekrutmen baru, A/B testing, dan lain sebagainya, yang menurutnya penting dalam membentuk effective engineer tersebut.
Dia mengambil contoh dari pengalamannya saat bekerja di Ooyala, Google, Quora, dan Quip. Tak ketinggalan juga contoh dari narasumbernya yang berasal dari Facebook, Dropbox, Box, dan perusahaan Silicon Valley lainnya. Banyak insight yang bisa kita peroleh dari buku ini.
August 6, 2015
I learnt a lot of things from this book, top on my list are
- Focus on high leverage tasks.
- Long hours don't make you an Effective Engineer.
- How important Estimation is when building products.
- Avoid one man teams.
- Automate mechanics.
This book is a great resource that every Software Engineer should read especially those that are just starting out.
- Focus on high leverage tasks.
- Long hours don't make you an Effective Engineer.
- How important Estimation is when building products.
- Avoid one man teams.
- Automate mechanics.
This book is a great resource that every Software Engineer should read especially those that are just starting out.
October 24, 2023
During reading the book, I mostly stumbled upon the stuff I digested before. However, it is a nice one-stop-shop to find ultimate engineering tenets.
If I’d get only one lesson from this book, it would be: “Time is our most finite asset, and leverage—the value we produce per unit time—allows us to direct our time towards what matters most. We should always ask ourselves: Does the work I’m doing provide the highest leverage for my current goal? If not, why am I doing it? Moreover, when we make the wrong choice—which is bound to happen over the course of our careers—a growth mindset allows us to view each failure as an opportunity to learn and do better next time.”
Some other takeaways from the chapters:
- Optimise for learning
- The earlier that you optimise for learning, the more time your learning has to compound. A good first job, for example, makes it easier to get a better second job, which then affects future career opportunities.
- Make sure that at least one of your languages is a scripting language (e.g., Python or Ruby) that you can use as your Swiss Army knife for quick tasks.
- Join a discussion group. In the eighteenth century, politician and inventor Benjamin Franklin organised a group of friends into a “club of mutual improvement”. The club met every Friday evening to discuss and debate “morals, politics, or natural philosophy,” providing members with a structured opportunity to improve themselves.
- Write to teach. That’s the technique that Physics Nobel Prize winner Richard Feynman used to learn faster.
- Prioritise Regularly
- Treat your brain as a processor, not as a memory bank.
- Work on the improvement and non-urgent. Prioritise long-term investments that increase your effectiveness, even if they don’t have a deadline.
- Reduce context switches. Don’t spend your cognitive energy actively juggling tasks.
- Make prioritisation a habit. Experiment to figure out a good workflow. Prioritise regularly, and it’ll get easier to focus on and complete your highest-leverage activities.
- Improve Your Project Estimation Skills
- “A good estimate” is an estimate that provides clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its target. - Steve McConnell in his book Software Estimation
- If a task will take more than two days, decompose it further.
- If you’ve made your estimates granular, you can defend them more easily.
- Use multiple approaches to estimate the same task. This can help increase confidence that your approach is sound. For example, suppose you’re building a new feature. You can 1) decompose the project into regular tasks, estimate each individual task, and create a bottom-up estimate; 2) gather historical data on how long it took to build something similar; and 3) count the number of subsystems you have to build and estimate the average time required for each one.
- When setting schedules, build in buffer time for the unexpected interruptions.
- Additional hours can burn out team members. In their book Peopleware, Tom DeMarco and Timothy Lister document a phenomenon they call “undertime”. The have found that overtime is “almost always followed by an equal period of compensatory undertime while the workers catch up with their lives.” Furthermore, they add, “the positive potential of working extra hours is far exaggerated, and that its negative impact…. can be substantial; error, burnout, accelerated turnover.”
- Work overtime only if you’re confident that it will enable you to finish on time.
- Define measurable tasks first. Clear milestones can alert you as to whether you’re on track or falling behind. Use them as opportunities to revise your estimates.
- Do the riskiest first. Reduce variance in your estimates and risk in your project by exploring the unknown early on. Don’t give yourself the illusion of progress by focusing first on what’s easy to do.
- Balance Quality with Pragmatism
- The engineering practices that work for Google would be overkill at a startup or a small company.
- At Quora, the author’s team only required reviews of model and controller code business logic; view code that rendered the web interface to users didn’t need to be reviewed.
- Establish a culture of reviewing code. Find the right balance between code reviews and tooling to trade off code quality and development speed.
- Minimise the Operation Burden
- The best that we can do is to “script for success,” practice failure scenarios, and work on our ability to recover quickly.
- Instagram grew and scaled successfully in part because the team didn’t spend all their time keeping their app up and running. Minimising our own operational burden means that we, too, can invest our time in more meaningful ways of driving impact.
- Invest in Your Team’s Growth
- “You’re a staff engineer if you’re making a whole team better than it would be otherwise. You’re a principal engineer if you are making the whole company better than it would be otherwise. And you’re distinguished if you’re improving the industry.” Marc Hedlund, VP of Engineering at Stripe
- Great Engineering Cultures:
- Optimise for iteration speed
- Push relentlessly towards automation
- Build the right software abstraction
- Focus on high code quality by using code reviews
- Maintain a respectful work environment
- Build shared ownership of code
- Invest in automated testing
- Allot experimentation time, either through 20% time or hackathons.
- Foster a culture of learning and continuous improvement.
- Hire the best.
If I’d get only one lesson from this book, it would be: “Time is our most finite asset, and leverage—the value we produce per unit time—allows us to direct our time towards what matters most. We should always ask ourselves: Does the work I’m doing provide the highest leverage for my current goal? If not, why am I doing it? Moreover, when we make the wrong choice—which is bound to happen over the course of our careers—a growth mindset allows us to view each failure as an opportunity to learn and do better next time.”
Some other takeaways from the chapters:
- Optimise for learning
- The earlier that you optimise for learning, the more time your learning has to compound. A good first job, for example, makes it easier to get a better second job, which then affects future career opportunities.
- Make sure that at least one of your languages is a scripting language (e.g., Python or Ruby) that you can use as your Swiss Army knife for quick tasks.
- Join a discussion group. In the eighteenth century, politician and inventor Benjamin Franklin organised a group of friends into a “club of mutual improvement”. The club met every Friday evening to discuss and debate “morals, politics, or natural philosophy,” providing members with a structured opportunity to improve themselves.
- Write to teach. That’s the technique that Physics Nobel Prize winner Richard Feynman used to learn faster.
- Prioritise Regularly
- Treat your brain as a processor, not as a memory bank.
- Work on the improvement and non-urgent. Prioritise long-term investments that increase your effectiveness, even if they don’t have a deadline.
- Reduce context switches. Don’t spend your cognitive energy actively juggling tasks.
- Make prioritisation a habit. Experiment to figure out a good workflow. Prioritise regularly, and it’ll get easier to focus on and complete your highest-leverage activities.
- Improve Your Project Estimation Skills
- “A good estimate” is an estimate that provides clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its target. - Steve McConnell in his book Software Estimation
- If a task will take more than two days, decompose it further.
- If you’ve made your estimates granular, you can defend them more easily.
- Use multiple approaches to estimate the same task. This can help increase confidence that your approach is sound. For example, suppose you’re building a new feature. You can 1) decompose the project into regular tasks, estimate each individual task, and create a bottom-up estimate; 2) gather historical data on how long it took to build something similar; and 3) count the number of subsystems you have to build and estimate the average time required for each one.
- When setting schedules, build in buffer time for the unexpected interruptions.
- Additional hours can burn out team members. In their book Peopleware, Tom DeMarco and Timothy Lister document a phenomenon they call “undertime”. The have found that overtime is “almost always followed by an equal period of compensatory undertime while the workers catch up with their lives.” Furthermore, they add, “the positive potential of working extra hours is far exaggerated, and that its negative impact…. can be substantial; error, burnout, accelerated turnover.”
- Work overtime only if you’re confident that it will enable you to finish on time.
- Define measurable tasks first. Clear milestones can alert you as to whether you’re on track or falling behind. Use them as opportunities to revise your estimates.
- Do the riskiest first. Reduce variance in your estimates and risk in your project by exploring the unknown early on. Don’t give yourself the illusion of progress by focusing first on what’s easy to do.
- Balance Quality with Pragmatism
- The engineering practices that work for Google would be overkill at a startup or a small company.
- At Quora, the author’s team only required reviews of model and controller code business logic; view code that rendered the web interface to users didn’t need to be reviewed.
- Establish a culture of reviewing code. Find the right balance between code reviews and tooling to trade off code quality and development speed.
- Minimise the Operation Burden
- The best that we can do is to “script for success,” practice failure scenarios, and work on our ability to recover quickly.
- Instagram grew and scaled successfully in part because the team didn’t spend all their time keeping their app up and running. Minimising our own operational burden means that we, too, can invest our time in more meaningful ways of driving impact.
- Invest in Your Team’s Growth
- “You’re a staff engineer if you’re making a whole team better than it would be otherwise. You’re a principal engineer if you are making the whole company better than it would be otherwise. And you’re distinguished if you’re improving the industry.” Marc Hedlund, VP of Engineering at Stripe
- Great Engineering Cultures:
- Optimise for iteration speed
- Push relentlessly towards automation
- Build the right software abstraction
- Focus on high code quality by using code reviews
- Maintain a respectful work environment
- Build shared ownership of code
- Invest in automated testing
- Allot experimentation time, either through 20% time or hackathons.
- Foster a culture of learning and continuous improvement.
- Hire the best.
November 2, 2020
Some helpful pointers on leverage (impact / time unit) and prioritization, which is the part I personally felt the most beneficial. Another part I liked was on how to improve project estimation, which is typically pretty hard especially for bigger and longer-term projects: it's easy to be weeks or even months delayed! This book includes a set of general guidelines for being a more successful engineer, and covers many broad areas. It's a good guidebook for an overview and a quick course-check if you are working as an engineer.
July 28, 2018
Where has this book been? I loved it!
It has great advice and principles for being a great engineer that don't have anything to do with designing systems and writing code - how to chose what to focus on, how to decide what projects to work on, the importance of investing in yourself, your tools and your colleagues.
It has great advice and principles for being a great engineer that don't have anything to do with designing systems and writing code - how to chose what to focus on, how to decide what projects to work on, the importance of investing in yourself, your tools and your colleagues.
November 9, 2015
Its a shit book
December 30, 2020
I've been reading this book for 3 years now and it had different values for different moments in my career. As a new grad (or as a junior software engineer), the first time I read this book, I saw it with a lot of great tips and started applying in my career. The second time I read this book I was a more senior engineer and had a lot of different experiences in my career.
Reading this book for the second time was like remembering good examples from my career and things I could apply in some moments.
For new engineers, I think this book can be very valuable. Senior engineers, though, probably had these experiences before, but I think it can also be valuable for them as well. By the way, we are always learning.
So here are the notes I liked and documented while reading this book:
## Dedicate time to develop a new skill
At Google, engineers have the 20/80 rule, where they can spend 20% of their time investing on innovation activities, personal projects, or learn new skills.
- Think of using 20% of the time to make investments that will make you more effective in the long run.
- Think of adjacent disciplines related to your core role. eg. product engineer learns product management, user research, frontend engineering. You can find adjacent disciplines to enrich your knowledge.
- Using the time to master the programming language that you use: focus on developing a solid grasp of the advanced concepts, read one or two good books, use platforms like [exercism](https://exercism.io/) to receive feedback on your code.
- Send Pull Requests to everyone you feel you can be benefited. Feedback on the code is really important to improve your coding skills. The feedback on the code can also start an interesting discussion about the language, clean code, system design, etc.
- Use the time to discuss software design and architecture.
- Have no fear jumping into code you don’t know: fear of failure hold us back. New codebases can be challenge at first, but we can always learn something new reading code.
- Use the time to study new technologies: programming languages, frameworks, tools, etc
- Read books: learn from lessons and mistakes of others. Re-apply knowledge without having to start from scratch.
- Join discussion groups: a group of people to discuss and talk about a specific topic.
- Attend talks / meetups / conferences. Maintain relationships
- Follow blogs / Write posts
- Build side projects / do what you love: hone your skills and do something that interest you.
## Prioritize Regularly
There will always be more tasks to do than you have time for. Working on one task means not working on another. This is why prioritization is so important. Some tasks will have more impact and more value (business or engineering value) than others. It's important to sort these tasks.
- List everything you need to do to start prioritizing: "the human brain is optimized for processing, not for storage." - David Allen, Getting Things Done
- Sort tasks by leverage: Estimate work by percentage of impact (0.1%, 1%, 10%, 100%) and the time each would take to implement (hours, days, weeks, months). With this visibility, we start to understand how we can prioritize by value and effort/time.
- Focus on what directly produces value: "when you get the important things right, the small things often don't matter". At the end of the day, what matters is how much value you've created. Don't try to get everything done. Focus on what matters - and what matters is what produces value. This value can be a business value like increase percentage of conversion in the landing page. Or it can be an engineering value like refactor this module, because it was a tech debit and will make the software easier to maintain and the developers more productive.
## Productivity Engineering
We can always improve the developer experience and productivity.
- Use the Checklist Manifesto by Dr. Atul Gawande: adoption of checklists has drastically reduced errors in fields after fields. eg. Pilots with pre-flight checklists. Surgeons with operations checklist. ToDo list for a feature implementation, from database design to backend to frontend, and automated tests.
- Protect your schedule: engineers need longer and more contiguous blocks of time. Focused time, called by *flow* by psychologist Mihály Csíkszentmihályi. *Flow* is a state of effortless concentration so deep that they lose their sense of time, of themselves, of their problems. When possible preserve larger blocks of focused time in your schedule.
- Limit the amount of work in progress: it can be tempting to try to tackle many things at once. When we fragment our attention too much, we end up reducing our overall productivity
## Invest in iteration speed
To improve the iteration speed, we need to basically improve the engineering cycle. From when the engineer gets a new task to shipping it to production. When the iteration speed is fast, we take business opportunities and we learn faster.
- Move fast to learn fast: The faster that you can iterate, the more that you can learn about what works and what doesn't work. With the "Move fast and break things" mantra, Facebook is a brilliant example of why investing in iteration speed is such a high-leverage decision. Many new employees ship code to production in their first few days. Facebook's culture emphasizes iterating quickly and focusing on impact rather than being conservative and minimizing mistakes. When you move too slowly trying to avoid mistakes, you lose opportunities.
- Invest in time-stamping tools
- "I’ve found that almost all successful people write a lot of tools. A very good indicator of future success of the first things a person did on a problem was to write a tool." - Bobby Johnson, former Facebook director of infrastructure engineering.
- "if you have to do something manually more than twice, then write a tool for the third time" - Raffi Krikorian, former VP of Platform Engineering at Twitter.
- The time-saving tools also scale with team adoption. A tool that saves you one hour per day saves 10 times as much when you get 10 people on your team to use it. That's why companies like Google, Facebook have entire teams devoted to improving internal development tools.
## **Master your programming environment**
To improve your experience developing software, mastering your coding environment is essential to be productive.
- **Get proficient with your favorite text editor or IDE**: figure out the workflows for efficient file navigation, search, replace, auto-completion. Learn and practice.
- **Get familiar with shell commands**: use grep, sort, uniq, find, wc, awk, etc.
- **Prefer keyboard over mouse**: moving our hands back and forth from the keyboard to the mouse takes time. Many applications offer keyboard shortcuts. This an opportunity for optimization.
- **Automate your manual workflows**: as a rule of thumb, once you've manually performed a task three or more times, start thinking if it would be worthwhile to automate that task. Example: setup a hot reload for frontend development. When you update the HTML or CSS files, it would automatically update the browser.
- **Test out ideas on an interactive interpreter**: Python, Ruby, and Javascript have interpreters available to test your code. Use it to build confidence that your program behaves as expected. The REPL is a very good tool to test our code and consistently get feedback.
## Measure what you want to improve
To see if our work is having a real impact, we need metrics.
Google, for example, use metrics for the quality of the search
- Dan Russel, tech lead responsible for search quality at Google, explains that user happiness is correlated to "that sense of delight". Example: when a user query `28 euro to usd` and automatically converts it to you.
- Steven Levy: the best indication of user happiness is "long click". When someone clicks a search result and doesn't return to the search page, or stays on the result page for a long time.
- A good example of the frontend world is the performance metrics for the browser. Google created the Web Vitals, the way to measure user experience related to web performance.
- What you don't measure is important as well: most call centers asses the performance of customer service representatives using their "average handle time". Reducing this metric saves costs because employees handle more phone calls per day. But this was not something that Tony Hsieh, Zappos CEO, actually want to optimize for. "This [metric] translates into reps worrying about how quickly they can get a customer off the phone, which in our eyes is not delivering great customer service.. we just care about whether the rep goes above and beyond for every customer".
- Internalize useful numbers: Percona can audit your database and show how well it's performing. They internalize useful numbers as how slow queries are, number of connections, so they can benchmark a particular system's performance. The knowledge of useful numbers provides a valuable shortcut for knowing where to invest effort to maximize gains.
## Instrument everything to understand what is going on
Monitoring errors and system reliability have a huge importance in software engineering.
- Jack Dorsey, Twitter Co-Founder, told that one of the most valuable lessons he learned years at Twitter was the importance of instrument everything. "For the first 2 years of Twitter, we were flying blind. We had no idea what was going on with the network. We had no idea what was going on with the system, because we could not see what was happening". After Twitter engineers started monitoring and instrumenting their systems were they able to identify problems and build a much more reliable service.
- Adopting a mindset of instrumentation means ensuring we have a set of dashboard that surface key health metrics and that enable us to drill down the relevant data.
## Validate your ideas early and quickly
Sometimes we have ideas to make the product or the software better, but we are not sure if it really works. Validate your ideas early and quickly to see if it is worth the time and effort, if it can be improved.
- Iteration provides opportunities to validate new ideas. Iterate quickly to validate quickly.
- Little efforts to validate if it is worth doing large implementations. It can be a very small implementation to see if the idea works. It can talking to a more experienced engineer to see if you are not forgetting anything. It can be presentation for the team explaining the change you want to do. It can be a ADR (Architecture Decision Record). Find ways to get feedback.
- Reduce risks by breaking the project in small pieces. When you have smaller pieces, you have more control and less risks of doing the wrong thing or doing much more than the expected. This idea works well when refactoring a legacy codebase. Refactor very small pieces, run the tests, and see how the system behaves.
## Balance quality with pragmatism
As software engineers, we always need to strive for quality. Sometimes we don't control over the quality because of a deadline or any other issue in the project. But we always need to find opportunities to the best work possible, but with pragmatism.
Implementing an abstraction that will take 2 days but will improve the software quality and make developers productive is a good idea. Implementing an abstraction that will take a month can be a signal to not do it now.
The idea is to write down the tradeoffs and find the balance in our decisions.
- Manage complexity through abstraction: it solves the hard problems once and enables the solutions to be used multiple times.
- "Pick the right ones (abstraction), and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely to fit in without extensive reorganization. Pick the wrong ones, and programming will be a series of nasty surprises; interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make"
## Activities where automation can help
- Validating that a piece of code, an interaction, or a system behaves as expected
- Detecting spikes in the error rate
- Checking code to ensure it conforms to style guidelines
Reading this book for the second time was like remembering good examples from my career and things I could apply in some moments.
For new engineers, I think this book can be very valuable. Senior engineers, though, probably had these experiences before, but I think it can also be valuable for them as well. By the way, we are always learning.
So here are the notes I liked and documented while reading this book:
## Dedicate time to develop a new skill
At Google, engineers have the 20/80 rule, where they can spend 20% of their time investing on innovation activities, personal projects, or learn new skills.
- Think of using 20% of the time to make investments that will make you more effective in the long run.
- Think of adjacent disciplines related to your core role. eg. product engineer learns product management, user research, frontend engineering. You can find adjacent disciplines to enrich your knowledge.
- Using the time to master the programming language that you use: focus on developing a solid grasp of the advanced concepts, read one or two good books, use platforms like [exercism](https://exercism.io/) to receive feedback on your code.
- Send Pull Requests to everyone you feel you can be benefited. Feedback on the code is really important to improve your coding skills. The feedback on the code can also start an interesting discussion about the language, clean code, system design, etc.
- Use the time to discuss software design and architecture.
- Have no fear jumping into code you don’t know: fear of failure hold us back. New codebases can be challenge at first, but we can always learn something new reading code.
- Use the time to study new technologies: programming languages, frameworks, tools, etc
- Read books: learn from lessons and mistakes of others. Re-apply knowledge without having to start from scratch.
- Join discussion groups: a group of people to discuss and talk about a specific topic.
- Attend talks / meetups / conferences. Maintain relationships
- Follow blogs / Write posts
- Build side projects / do what you love: hone your skills and do something that interest you.
## Prioritize Regularly
There will always be more tasks to do than you have time for. Working on one task means not working on another. This is why prioritization is so important. Some tasks will have more impact and more value (business or engineering value) than others. It's important to sort these tasks.
- List everything you need to do to start prioritizing: "the human brain is optimized for processing, not for storage." - David Allen, Getting Things Done
- Sort tasks by leverage: Estimate work by percentage of impact (0.1%, 1%, 10%, 100%) and the time each would take to implement (hours, days, weeks, months). With this visibility, we start to understand how we can prioritize by value and effort/time.
- Focus on what directly produces value: "when you get the important things right, the small things often don't matter". At the end of the day, what matters is how much value you've created. Don't try to get everything done. Focus on what matters - and what matters is what produces value. This value can be a business value like increase percentage of conversion in the landing page. Or it can be an engineering value like refactor this module, because it was a tech debit and will make the software easier to maintain and the developers more productive.
## Productivity Engineering
We can always improve the developer experience and productivity.
- Use the Checklist Manifesto by Dr. Atul Gawande: adoption of checklists has drastically reduced errors in fields after fields. eg. Pilots with pre-flight checklists. Surgeons with operations checklist. ToDo list for a feature implementation, from database design to backend to frontend, and automated tests.
- Protect your schedule: engineers need longer and more contiguous blocks of time. Focused time, called by *flow* by psychologist Mihály Csíkszentmihályi. *Flow* is a state of effortless concentration so deep that they lose their sense of time, of themselves, of their problems. When possible preserve larger blocks of focused time in your schedule.
- Limit the amount of work in progress: it can be tempting to try to tackle many things at once. When we fragment our attention too much, we end up reducing our overall productivity
## Invest in iteration speed
To improve the iteration speed, we need to basically improve the engineering cycle. From when the engineer gets a new task to shipping it to production. When the iteration speed is fast, we take business opportunities and we learn faster.
- Move fast to learn fast: The faster that you can iterate, the more that you can learn about what works and what doesn't work. With the "Move fast and break things" mantra, Facebook is a brilliant example of why investing in iteration speed is such a high-leverage decision. Many new employees ship code to production in their first few days. Facebook's culture emphasizes iterating quickly and focusing on impact rather than being conservative and minimizing mistakes. When you move too slowly trying to avoid mistakes, you lose opportunities.
- Invest in time-stamping tools
- "I’ve found that almost all successful people write a lot of tools. A very good indicator of future success of the first things a person did on a problem was to write a tool." - Bobby Johnson, former Facebook director of infrastructure engineering.
- "if you have to do something manually more than twice, then write a tool for the third time" - Raffi Krikorian, former VP of Platform Engineering at Twitter.
- The time-saving tools also scale with team adoption. A tool that saves you one hour per day saves 10 times as much when you get 10 people on your team to use it. That's why companies like Google, Facebook have entire teams devoted to improving internal development tools.
## **Master your programming environment**
To improve your experience developing software, mastering your coding environment is essential to be productive.
- **Get proficient with your favorite text editor or IDE**: figure out the workflows for efficient file navigation, search, replace, auto-completion. Learn and practice.
- **Get familiar with shell commands**: use grep, sort, uniq, find, wc, awk, etc.
- **Prefer keyboard over mouse**: moving our hands back and forth from the keyboard to the mouse takes time. Many applications offer keyboard shortcuts. This an opportunity for optimization.
- **Automate your manual workflows**: as a rule of thumb, once you've manually performed a task three or more times, start thinking if it would be worthwhile to automate that task. Example: setup a hot reload for frontend development. When you update the HTML or CSS files, it would automatically update the browser.
- **Test out ideas on an interactive interpreter**: Python, Ruby, and Javascript have interpreters available to test your code. Use it to build confidence that your program behaves as expected. The REPL is a very good tool to test our code and consistently get feedback.
## Measure what you want to improve
To see if our work is having a real impact, we need metrics.
Google, for example, use metrics for the quality of the search
- Dan Russel, tech lead responsible for search quality at Google, explains that user happiness is correlated to "that sense of delight". Example: when a user query `28 euro to usd` and automatically converts it to you.
- Steven Levy: the best indication of user happiness is "long click". When someone clicks a search result and doesn't return to the search page, or stays on the result page for a long time.
- A good example of the frontend world is the performance metrics for the browser. Google created the Web Vitals, the way to measure user experience related to web performance.
- What you don't measure is important as well: most call centers asses the performance of customer service representatives using their "average handle time". Reducing this metric saves costs because employees handle more phone calls per day. But this was not something that Tony Hsieh, Zappos CEO, actually want to optimize for. "This [metric] translates into reps worrying about how quickly they can get a customer off the phone, which in our eyes is not delivering great customer service.. we just care about whether the rep goes above and beyond for every customer".
- Internalize useful numbers: Percona can audit your database and show how well it's performing. They internalize useful numbers as how slow queries are, number of connections, so they can benchmark a particular system's performance. The knowledge of useful numbers provides a valuable shortcut for knowing where to invest effort to maximize gains.
## Instrument everything to understand what is going on
Monitoring errors and system reliability have a huge importance in software engineering.
- Jack Dorsey, Twitter Co-Founder, told that one of the most valuable lessons he learned years at Twitter was the importance of instrument everything. "For the first 2 years of Twitter, we were flying blind. We had no idea what was going on with the network. We had no idea what was going on with the system, because we could not see what was happening". After Twitter engineers started monitoring and instrumenting their systems were they able to identify problems and build a much more reliable service.
- Adopting a mindset of instrumentation means ensuring we have a set of dashboard that surface key health metrics and that enable us to drill down the relevant data.
## Validate your ideas early and quickly
Sometimes we have ideas to make the product or the software better, but we are not sure if it really works. Validate your ideas early and quickly to see if it is worth the time and effort, if it can be improved.
- Iteration provides opportunities to validate new ideas. Iterate quickly to validate quickly.
- Little efforts to validate if it is worth doing large implementations. It can be a very small implementation to see if the idea works. It can talking to a more experienced engineer to see if you are not forgetting anything. It can be presentation for the team explaining the change you want to do. It can be a ADR (Architecture Decision Record). Find ways to get feedback.
- Reduce risks by breaking the project in small pieces. When you have smaller pieces, you have more control and less risks of doing the wrong thing or doing much more than the expected. This idea works well when refactoring a legacy codebase. Refactor very small pieces, run the tests, and see how the system behaves.
## Balance quality with pragmatism
As software engineers, we always need to strive for quality. Sometimes we don't control over the quality because of a deadline or any other issue in the project. But we always need to find opportunities to the best work possible, but with pragmatism.
Implementing an abstraction that will take 2 days but will improve the software quality and make developers productive is a good idea. Implementing an abstraction that will take a month can be a signal to not do it now.
The idea is to write down the tradeoffs and find the balance in our decisions.
- Manage complexity through abstraction: it solves the hard problems once and enables the solutions to be used multiple times.
- "Pick the right ones (abstraction), and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely to fit in without extensive reorganization. Pick the wrong ones, and programming will be a series of nasty surprises; interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make"
## Activities where automation can help
- Validating that a piece of code, an interaction, or a system behaves as expected
- Detecting spikes in the error rate
- Checking code to ensure it conforms to style guidelines
September 29, 2019
Reading this book is indeed a high-leverage activity which the author explains throughout the book.
April 20, 2023
Focus sharpened!
This was fine, but kind of redundant to my existing knowledge. The first couple chapters sold itself as a down with workaholism manifesto, which intrigued me, but then it kind of transitioned to a book about unit tests and code reviews.
This was fine, but kind of redundant to my existing knowledge. The first couple chapters sold itself as a down with workaholism manifesto, which intrigued me, but then it kind of transitioned to a book about unit tests and code reviews.
August 27, 2023
This book includes a decent exploration of engineering principles but the author’s habit of name-dropping different parts of his resume and refusal to admit he was ever on an unsuccessful project makes this a tough read.
One habit of the author I particularly dislike is citing one successful anecdote as if it proves a rule. For example, he states that Google’s use of code review makes it a successful company. To imply that such a small engineering decision caused such an outsized impact is ridiculous. Oh, Google has red, blue, green and yellow in their logo. If I do that for my startup will we also become a billion dollar company? He has good instincts on engineering principles but is pretty bad at defending them.
If you’re an entry-level software engineer, this could introduce some interesting ideas around trade-offs and best practices, but I also think there MUST be other books that are less self-congratulatory and more nuanced.
One habit of the author I particularly dislike is citing one successful anecdote as if it proves a rule. For example, he states that Google’s use of code review makes it a successful company. To imply that such a small engineering decision caused such an outsized impact is ridiculous. Oh, Google has red, blue, green and yellow in their logo. If I do that for my startup will we also become a billion dollar company? He has good instincts on engineering principles but is pretty bad at defending them.
If you’re an entry-level software engineer, this could introduce some interesting ideas around trade-offs and best practices, but I also think there MUST be other books that are less self-congratulatory and more nuanced.
September 8, 2017
It's a kind of book which should be read at the earliest possible. The book delivers what the title proclaims and more - it's good for startups too. Read this book to find out -
- Importance and the process of hiring
- Importance of documentation, knowledge sharing and on boarding process for new hires
- Leverage activities - Doings tasks that result in proportionately high values
- Tasks prioritization and scheduling and procrastination
- Unit test and automation. And how companies are adopting automation to iterate quickly
- A/B Testing and so on
- Importance and the process of hiring
- Importance of documentation, knowledge sharing and on boarding process for new hires
- Leverage activities - Doings tasks that result in proportionately high values
- Tasks prioritization and scheduling and procrastination
- Unit test and automation. And how companies are adopting automation to iterate quickly
- A/B Testing and so on
February 19, 2021
Some great points brought up in this book. I think the book sometimes goes away from "The Effective Engeineer" and starts to focus on "The Effective Team" a little bit too much. Of course, it's hard to be an effective engineer without working in an effective engineer and there's only so much you can do on an individual level but most of the team stuff can be found in other books as well and aren't really unique. It's the parts on what you can do as an individual that makes this book stand out.
January 14, 2018
Absolutely packed with highly relevant information. Somewhat biased towards engineers at SaaS companies, however many of the lessons are widely applicable.
Certainly a great starting point for new engineers, but with lessons and anecdotes that experienced engineers could surely learn from.
Certainly a great starting point for new engineers, but with lessons and anecdotes that experienced engineers could surely learn from.
December 30, 2016
Отличнейшая книга. По итогам записал себе строк 300 заметок. Похожа на Soft Skills Сомнеза, но с намного большим техническим уклоном.
December 16, 2021
My manager was recommending books to me now and then and the stack was growing, so I thought let's start reading this one. The Effective Engineer revolves around ways to make you an impactful, smart software engineer and let you retrospect the way you work.
The book has been very impactful for me. I would retrospect my way of working, how I am investing my time in work and start asking myself if what I am doing next is worthwhile. I very much want to adopt a disciplined work habit. It’s not easy to adopt that though. Because time is constrained, there is so much to catch up at the starting period of my career and I am a human being who gets excited and sad proportional to the success and failure of a piece of code run. I wanted to break the habit of driving my mood on a piece of code, wanted to adopt a strict routine where I would get up from my chair even if the goal of the day is not accomplished. Still I am struggling. The book helped me in the journey by making me conscious about ‘Why I am not able to accomplish my goal’, ‘how can I estimate better’ and so more.
The book goes on with the best practices for a software engineer to the best practices of a software team. It tells us precisely where to focus, how to focus. A very logical and smart approach for engineering problems! The only thing I felt missing is a human approach. A software engineer is above all a human being. So building the best engineering habit might start from adopting a healthy life, I believe. The book doesn’t touch that side. I don’t mind though, because the scope would be too much then and I am now in a position where my life is set well, I just need to enhance my career in a sophisticated manner.
A very well focused book that would effectively help an engineer grow.
The book has been very impactful for me. I would retrospect my way of working, how I am investing my time in work and start asking myself if what I am doing next is worthwhile. I very much want to adopt a disciplined work habit. It’s not easy to adopt that though. Because time is constrained, there is so much to catch up at the starting period of my career and I am a human being who gets excited and sad proportional to the success and failure of a piece of code run. I wanted to break the habit of driving my mood on a piece of code, wanted to adopt a strict routine where I would get up from my chair even if the goal of the day is not accomplished. Still I am struggling. The book helped me in the journey by making me conscious about ‘Why I am not able to accomplish my goal’, ‘how can I estimate better’ and so more.
The book goes on with the best practices for a software engineer to the best practices of a software team. It tells us precisely where to focus, how to focus. A very logical and smart approach for engineering problems! The only thing I felt missing is a human approach. A software engineer is above all a human being. So building the best engineering habit might start from adopting a healthy life, I believe. The book doesn’t touch that side. I don’t mind though, because the scope would be too much then and I am now in a position where my life is set well, I just need to enhance my career in a sophisticated manner.
A very well focused book that would effectively help an engineer grow.
July 12, 2017
How many times as a software engineer you had to work 60 to 70 hours a week to meet a deadline, fighting some prod issue or facing some other urgent situations? But that doesn't sustain. As an engineer if you have to spend a lot of hours at work, sacrificing your life or family time, then you probably should rethink and figure out how you can balance. The answer is - be efficient. Instead of working more hours work more efficiently. Study also shows working more hours doesn't usually produce more. It is possible working long hours causes less production than a normal 40 hours work week in the long run.
Edmond Lau explains why it is so important to focus on being efficient. He added a lot of suggestions and techniques how engineers should think in to achieve different purposes efficiently. Before doing any work we should always ask ourself what other thing we can do which gives us more leverage.
To produce more in the long run we should focus on few things -
Edmond also gave a lot of examples from his personal experience in company like Google, Facebook, Quora, Ooyala, Quip which are extremely valuable. In Google, I already got a chance to practice many of these. But still those suggestions are good reminders for me.
I highly recommend this book. The earlier stage of software engineering life you are in the more value this book can bring to you.
Edmond Lau explains why it is so important to focus on being efficient. He added a lot of suggestions and techniques how engineers should think in to achieve different purposes efficiently. Before doing any work we should always ask ourself what other thing we can do which gives us more leverage.
To produce more in the long run we should focus on few things -
1. Optimize for iteration speed
2. Prioritize on automation
3. Simplify engineers life by right software abstractions,
4. High quality code
5. Respectful work environment
6. Shared ownership of code
7. Test automation
8. Set some time aside to do some experimental works
9. Build a learning culture and focus on continuous improvement
10. Hire the best
Edmond also gave a lot of examples from his personal experience in company like Google, Facebook, Quora, Ooyala, Quip which are extremely valuable. In Google, I already got a chance to practice many of these. But still those suggestions are good reminders for me.
I highly recommend this book. The earlier stage of software engineering life you are in the more value this book can bring to you.
January 16, 2022
I wish I had read this book early on in my career, and I would highly recommend this to any software engineer, new as well as someone who is growing into the role of a tech lead/senior engineer. Over the past few months, I have been trying find ways to scale myself and improve my effectiveness, as I find myself short on time and overwhelmed with growing responsibilities. The book helped me, particularly, in two ways: 1. Validates some of the actions I have been taking towards the aforementioned goal and 2. Provides a holistic view (IMO) on all aspects of becoming an effective engineer. Being an effective engineer is not about producing thousands of lines of code by yourself, but effectiveness through project estimation, prioritization, mentoring, growing others is what makes an engineer more impactful . I could relate to almost all of the chapters in the book, though at times there was some repetition and very specific code/projects that the author worked on.
The closing note resonates profoundly “Time is our most finite asset, and leverage – the value we produce per unit of time – allows us to direct our time toward what matters most”.
The closing note resonates profoundly “Time is our most finite asset, and leverage – the value we produce per unit of time – allows us to direct our time toward what matters most”.
July 8, 2021
If you’ve been as lucky as I have been during my career, most things discussed in this book won’t wow you. For this reason, I can understand how someone wouldn’t consider this book revolutionary.
However, as experienced as you can be, this text touches on such important and critical points that remembering them becomes relevant regardless of your level of seniority. I would almost consider this book a mandatory reading for any engineer.
“The Effective Engine” book brings, not only great advices you should follow for your own benefit, but also fantastic tips so you influence a better engineering culture at your organisation.
However, as experienced as you can be, this text touches on such important and critical points that remembering them becomes relevant regardless of your level of seniority. I would almost consider this book a mandatory reading for any engineer.
“The Effective Engine” book brings, not only great advices you should follow for your own benefit, but also fantastic tips so you influence a better engineering culture at your organisation.
October 6, 2019
If you're a seasoned software engineer, you might not find this book very useful. However, as a new grad software engineer, I personally found it helpful to read about using the leverage framework to make decisions at work and to evaluate engineering culture at a company.
As the Rumpelstiltskin principle states, once you have a name for something, you have power over it. This book highlighted different aspects of software development that I can pay more attention to when interacting with my more senior coworkers.
Edmond references a lot of other famous works like Stephen Covey’s The 7 Habits of Highly Effective People, which might be a put off for some, but I actually enjoyed getting the essence of many books distilled down into a few sentences. It makes it easier to determine which books I should read later on my own time.
As the Rumpelstiltskin principle states, once you have a name for something, you have power over it. This book highlighted different aspects of software development that I can pay more attention to when interacting with my more senior coworkers.
Edmond references a lot of other famous works like Stephen Covey’s The 7 Habits of Highly Effective People, which might be a put off for some, but I actually enjoyed getting the essence of many books distilled down into a few sentences. It makes it easier to determine which books I should read later on my own time.
May 5, 2019
The book inspires engineer to have better habits at working place. The illustrations for each principle are from stories of big companies make me convinced.
October 28, 2019
Use leverage as the key anchor to determine where to spend your time, the most finite and valuable asset
September 24, 2022
Yes. I finally got around to the end. I have to say, this is quite a great book. I had reservations coming from one or two reviews but I'm glad I went forth with the read. A must read for a software engineer out there.
Perhaps one of my concerns are the missing links. The random 404 or 503 on a number of references. Other than that, I walked through all of those links like I couldn't live without.
Perhaps one of my concerns are the missing links. The random 404 or 503 on a number of references. Other than that, I walked through all of those links like I couldn't live without.
Displaying 1 - 30 of 253 reviews