Book Summary: The Effective Engineer by Edmond Lau

A Great Read for New Engineers

Introduction

I just finished reading The Effective Engineer by Edmond Lau, and it was an amazing read for someone who is just starting out their engineering career. So, I will break down the lessons I extracted from it by chapter below and then an overall summary.

The book is broken down into 3 parts:

• Part 1: Adopt the Right Mindset (Ch. 1, 2, 3)
• Part 2: Execute, Execute, Execute (Ch. 4, 5, 6, 7)
• Part 3: Build Long-Term Value (Ch. 8, 9, 10)

Chapter Summaries

Chapter 1: Focus on High Leverage Activities

Lau sets the foundation for how to approach any problem that you encounter as an engineer, and that is to focus on high leverage activities, which he defines as

Impact Produced / Time Invested

With the way this is defined, there are only 3 ways to increase your leverage:

1. By reducing the time invested: Ask yourself, “how can I complete this activity in a shorter amount of time?”
2. By improving the impact produced: Ask yourself, “how can I increase the value produced by this activity?”
3. By shifting to a higher-leverage activity: Ask yourself, “is there something else I could spend my time on that would produce more value?”

You should be asking yourself these 3 questions every day. At the same time, be careful to avoid “easy wins” or to ignore non-urgent yet high leverage activities.

Chapter 2: Optimize for Learning

Learning compounds exponentially. The more you know, the easier it is to know more things and the more resourceful you become. Lau highlights this exponential factor in learning: if you optimize for learning, you may become slower today but you will become increasingly faster as time passes. Lau suggests that you devote about 20% of your time to learning. 20% is aggressive, but it pays off in the long run.

Here are some advice to do this:

• Try to get reviews from the harshest reviewers
• Try talking to the more senior engineers in your team and learn from them
• Get outside of your comfort zone more often
• Prioritize learning potential when choosing a new team
• Study code for core abstractions written by the best engineer at your company or on open source projects
• Jump fearlessly into code that you’re unfamiliar with

Chapter 3: Prioritize Regularly

Lau claims that the brain is better optimized for processing, and much less so for storing things. So, this implies that figuring out how you can make your work more processing-like is high leverage because it makes you utilize your brain more efficiently. There are many ways to do this, but the key is finding a way to plan what you are working on, such as a highly organized todo list. Prioritizing regularly helps you always stay on track with what has the most leverage, and then you can focus your energy on that.

Chapter 4: Invest in Iteration Speed

The big idea here is to optimize on things that can speed up the engineering process, such as writing continuous deployment system. I honestly didn’t feel that invested in this chapter, so this is as much as I can say. 😅

Chapter 5: Measure What You Want to Improve

How do you know that you’re improving if you’re not measuring what you want to improve? The short answer is: you don’t know, and that’s why it’s important to measure what you want to improve.

In addition, it’s also important to choose the right metrics to track. Some metrics, as benign as they can look, can incentivize bad behaviors. For instance, Lau talked about how if a software engineering team chooses the metric to be “number of bug fixed”, it might influence engineers to be less careful about the code they ship to production so that they can later fix the introduced bugs and thus improve the metric. A better metric in this case would be “number of outstanding bugs”, i.e., how many bugs ever make it to production code. This metric incentivizes engineers not to ship a buggy product. So, be careful about the behaviors that the metrics you choose incentivize.

In addition, your company or team should choose a small set of metrics that would better measure and guide the impact of the work that you are doing. These select few metrics can be seen as core to your product: the better they are, the better your product is. Lau mentioned 3 characteristics of a good metric:

• A good metric maximizes impact
• A good metric is actionable—the movement of this metric can be causally explained by your team’s and work’s effort
• A good metric is responsive yet robust—when it changes, it should be highly responsive to anything that causes it to change so that it gives quick feedback to the engineers

Chapter 6: Validate Your Ideas Early and Often

What Lau emphasizes is twofold. First, you have to validate whether the ideas that you have will actually be impactful. This sort of validation can come from conversations with your team, user survey, or from running A/B testing with the ideas implemented. With new ideas, it’s highly important to “find low effort ways to validate [your] work”.

Then secondly, you need to always aim to get some feedback as you make progress on the projects you are working on. It could be the case that you start working on a project that turns out to be harder than it previously seemed, which by definition lowers its leverage. While that was happening, maybe something else came up that could be higher leverage. In such cases, it may be better to drop the current project and focus on another one, and constantly validating the projects will help you determine the best decision to take.

Chapter 7: Improve Your Project Estimation Skills

This is one of those things that is really good to have but also that comes with time. However, Lau gave some pointers on how you can improve your estimation skills. In no particular order:

1. Try to view estimates as probability distributions rather than best-case scenarios. An example that he gave was to say something along these lines: “there’s a 50% likelihood that we can deliver the feature 4 weeks from now, and a 90% chance that we can deliver it within 8 weeks”.
2. Beware of anchoring bias: if someone said something like “Oh this should take no longer than 2 weeks”, that can easily influence you to think that would be the case even thought this particular task could take longer. The advice here is to avoid giving or accepting estimates before you’ve broken down your projects and did more work to provide a more accurate estimate.
3. Be aware that there exist multiple overhead costs. One statistic that he gave—which came from The Mythical Man-Month book by Frederick Brooks—is that for every additional member that joins your team, the communication overhead growth quadratically. In addition, small, daily interruptions can cause the timeline of a project to slip up, so give yourself some buffer time to account for overhead cost.
4. Use “time-boxing” to constraint open-ended tasks. For instance, don’t spend too much time thinking about which database to use for a project. “Time-boxing” this task would be equivalent to saying, “I will not spend more than 2 hours to do this. Whatever infrastructure I come up with in that time frame is what I will use”.

Another great tip that Lau gave was to make your project goals as specific as you possibly can. This in turn becomes really powerful because the specificity of the goal acts as a discriminator against random ideas that may come up along the way.

Chapter 8: Balance Quality with Pragmatism

Pragmatism—thinking in terms of what does and doesn’t work for achieving our goals—is a more effective lens through which to reason about quality.

That quote summarizes this chapter pretty well. Here, Lau suggested establishing a sustainable code review process that works for the size of your team or organization. The code review process at a company like Google or Facebook is probably going to be overkill for a startup. Other suggestions were to manage complexity through the right kind of abstractions—Joshua Block’s “How to Design Good API and Why It Matters” talk is a great example of this, automating testing, and repaying technical debt.

Chapter 9: Minimize Operational Burden

It’s easy to get caught up with using the new technologies that come up (especially in say, Web Development); however, this chapter focuses on the idea that if you’re really serious about your project, you want to minimize operational burden as much as you can. Using a new technology that may not have extensive documentation and/or developer support might not be a wise decision in the long term. Similarly, when building your system, embrace simplicity as much as possible, and automate anything that is mechanical.

Another important idea is to make batch processes idempotent. Batch processes are scripts that when executed, do not require much human supervision. When that kind of script is idempotent, it means that its output is the same regardless of how many times it’s ran. The advantage with idempotent scripts is that you can run them more often, which is useful when this kind of scripts gives you some sort of validation that your system works (e.g., integrations / unit tests) or provides you with new, useful, and actionable information (e.g., realtime data analytics).

Chapter 10: Invest in Your Team’s Growth

Lau explains how your success—and failures—is predicated on the success or failure of your team. Just think about companies that are successful: in those companies, pretty much all engineers are highly regarded. On the flip side, when a team has a failure, anyone member’s success gets diluted. This is why Lau cited this quote from Andy Rachleff, co-founder of Benchmark Capital:

You get more credit than you deserve for being part of a successful company, and you get less credit than you deserve for being part of an unsuccessful company.

Lau also describes how you do not want to be the only engineer who understands a given system. This may seem counterintuitive at first, because if you’re the only one who knows how a system works, it gives you job security because your organization needs you for that system. However, you become a bottleneck for your team. If that particular system breaks while you’re on vacation, who is going to fix it? You are going to fix it because no one else can. So, your team becomes more successful when more engineers understands your systems because your team becomes more resilient to failures that way, and when your team is more successful, you are more successful.

My Takeaways

This book packs so much wisdom in it. It was quite an experience to learn from some of the bests in the field, and I believe it sets me up better for the software engineering career that I’m just beginning. At the same time, I will need to periodically come back to this because there’s no way I’ve become a master of it from just one read through.

With that said, the simplicity of Lau’s definition of leverage is powerful. One can derive the rest of the wisdoms in this book just from that definition in the first chapter, so it’s something that I am drilling into my brain to remember. I will use that concept from now on when evaluating decisions that I am making not just in my engineering career but also in pretty much anything I do.

In addition, the rest of the book gave me a lot of pointers on how I can optimize my everyday activities. At the core of it, I need to devote time to learning, ruthlessly prioritizing, automate repetitive and mechanical tasks, measure what I want to improve, validate my ideas early and often, approach problems with pragmatism- and simplicity-oriented solutions, and always try to support the success of my friends, teams, or communities given how much that is interconnected with my own success. I also believe that these lessons carry over to life, so I will apply them there too.