Book Summary: The Effective Engineer

Part 1: Adopt the Right Mindset

Focus on High-Leverage Activities

Lau’s central premise is to increase leverage, which he defines as follows:

$\text{Leverage} = \frac{\text{Impact Produced}}{\text{Time Invested}}$

Given the above formula, there are only three ways to increase leverage, increase impact, decrease time invested or work on something else. Correspondingly, Lau provides three questions, designed to guide engineers to higher leverage activities:

1. How can I complete this activity in a shorter amount of time?
2. How can I increase the value produced by this activity?
3. Is there something else I can work on that will produce more value?

Optimize for Learning

Lau explains that learning is a high-leverage activity due to its exponential growth. As engineers build their base of knowledge, the combination of learned skills increases the areas to which an engineer can contribute. The increased depth and breadth an engineer can contribute to making learning a high-leverage activity. An engineer should regularly invest in active learning. Lau suggests the following avenues:

• Study code for core abstractions at your company, e.g., Google’s MapReduce.
• Write more code.
• Take classes on broad topics related to software engineering.
• Master programming languages.
• Pick the harshest critic for code review.
• Participate in design discussions, even if they are unrelated.
• Pick diverse projects.
• Select teams with a few senior engineers so you can learn from their experience.
• Fearlessly jump into code.

Prioritize Regularly

To stay committed to high-leverage activities, regularly review how you rank activities. Lau recommends a simple, ordered to-do list. However, ranking all items on a to-do list is not beneficial, as the difference between the 87th and 88th item isn’t significant. Instead, identify a few goals and conduct a pairwise comparison between goals, focusing on items that directly produce value. Lau uses the Eisenhower matrix to compare an activity’s importance and urgency.

Part 2: Execute, Execute, Execute

Invest in Iteration Speed

Lau strongly advocates for continuous delivery, which is “the ability to get changes of all types […] into production safely and quickly”. He cites the following benefits for continuous delivery:

• Allows small changes.
• Eliminates overhead of release process.
• Reduces context switching because you can make sweeping changes in one afternoon instead of spread across several weeks, i.e., a database schema upgrade.
• Allows for new development techniques.
• Enables faster iteration. Mark Zuckerberg and Facebook develop by this motto: “If you never break anything you’re probably not moving fast enough.”

Effective engineers invest in tools to increase efficiency. Data from Facebook shows that engineers who invest in their tools are more effective. Tools can range from shell scripts up to full automation platforms for testing and deployment. In addition to engineering efficiencies, Lau reminds readers to examine non-engineering bottlenecks like meetings, long-winded standups, and one-on-one meetings.

Measure What You Want to Improve

Lau cites the importance of finding a good metric, using the example of Google’s long click. After a user clicks a search result, a long click occurs when the user stays on the page, indicating the search results were successful. A short click is when the user immediately returns to the start page, indicating an unhelpful search result.

Metrics drive progress. For difficult-to-quantify metrics, Lau suggests using user surveys and asking the following questions:

• Is there some way to measure the progress of what I’m doing?
• If this task doesn’t move a core metric, is it worth doing?

Metrics should be carefully chosen since they might have unintended consequences. For example, the number of weekly active users is not nearly as telling as weekly active users by cohort. Rapid growth can hide user abandonment if the metric only accounts for weekly active users. A good metric possesses the following qualities:

• Maximizes impact.
• Actionable. The movement of a metric is causally explained by something the engineering team did.
• Responsive. The metric updates quickly enough to provide timely feedback.
• Robust. The metric isn’t overly influenced by external factors.

Lau borrows from Jim Collins’ book, Good to Great, and advocates for a single core metric called the economic denominator. The economic denominator answers the question: “If you could only pick one ratio – profit per $x$ – to systematically increase over time, what $x$ would have the greatest and most sustainable impact on your economic engine?” ²

Once a metric is decided, an engineer should instrument everything about the product to ensure they aren’t flying blind. Lau encourages understanding the following numbers to sanity check measurements. The following times typify the most common examples of times in software.

To better grasp the vast time differences, if an L1 cache reference took one second, a round trip from CA to the Netherlands would take about ten years.

Lau warns that analytics pipelines are not nearly as well tested as application code, so managers and engineers should be skeptical of data integrity. To restore confidence in analytics, create a pipeline with the following guidelines.

• Log data liberally.
• Build tools to iterate on data sooner.
• Run end-to-end integration tests on analytics.
• Examine collected data sooner.
• Cross-validate by computing metrics in multiple ways.
• When numbers look off, dig into the problem.

Validate Your Ideas Early and Often

Avoid investing time into products with an unknown chance of success. Work towards a minimum viable product (MVP), validated with a prototype, static site, or in Dropbox’s case, a video. After releasing an MVP, continuously validate with A/B testing. For A/B testing, hone in on differences that are high-leverage and of practical significance. At a startup’s scale, shades of blue are not usually significant. At Google’s scale, the right shade of blue might mean millions of dollars of additional revenue.

Improve Your Project Estimation Skills

Use accurate estimates to drive project planning with the following techniques:

• Decompose tasks into granular subtasks.
• Model how long a task will take as a probability distribution.
• The person who does the work does the estimate.
• Beware of anchoring bias.
• Validate estimate against historical data.
• Budget for unknowns.

When estimating projects, define specific goals and measurable milestones. Reduce risk early by tackling the riskiest areas first. Approach rewrites with extreme caution.

Part 3: Build Long-Term Value

Balance Quality with Pragmatism

Lau stresses the importance of a sustainable code review process. He describes techniques for keeping code quality high while also allowing for rapid development.

Use abstractions to manage complexity. Lau’s advice mirrors Steve McConnell’s maxim that the “managing complexity is the primary goal of software construction.” Echoing, Joshua Bloch’s advice on designing APIs, Lau states that good abstractions should be:

• Easy to learn.
• Easy to use even without documentation.
• Hard to misuse.
• Sufficiently powerful to satisfy requirements.
• Easy to extend.
• Appropriate to the audience.

Lau advocates for automated testing and repaying technical debt to keep development velocity high.

Minimize Operational Burden

Inspired by Instagram’s mantra of “do the simple thing first”, Lau highlights the embrace operation simplicity instead of new technologies. When reviewing designs, ask if this design is the simplest approach. Design technology to fail fast; the sooner a component fails the easier it is to debug.

Lau advocates for engineers to relentlessly automate mechanical tasks. Lau argues that engineers should automate more but usually don’t because they don’t have time at the current moment. As a result, writing tools suffers from the tragedy of the commons. The collective time saved by automation vastly exceeds the initial time commitment required to add automation. However, the time saved by automation rarely pays off for a single engineer resulting in a tragedy of the commons. Other reasons for not investing in tools include a lack of familiarity with automation tools, underestimating the frequency of the task, and a tendency to not internalize the time savings over months and years.

Invest in Your Team’s Growth

Lau ends the book with recommendations on how to grow a team. He recommends making hiring everyone’s responsibility, crafting a good onboarding process, sharing ownership of code, building collective wisdom through postmortems, and establishing a great engineering culture. Lau says the following traits indicate a great engineering team:

• Optimize for iteration speed.
• Push relentlessly towards automation.
• Build the right software abstractions.
• 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.

Ten Books Every Effective Engineer Should Read

Lau closes with 10 book recommendations.

• Peopleware: Productive Projects and Teams
• Team Geek: A software Developer’s Guide to Working Well with Others
• High Output Management
• Getting Things Done: The Art of Stress-Free Productivity
• Four Hour Work Week: Escape 9-5, Live Anywhere, and Join the New Rich
• 7 Habits of Highly Effective People: Powerful Lessons in Personal Change
• Conscious Business: How to Build Value Through Values
• Your Brain at Work: Strategies for Overcoming Distraction Regaining Focus and Working Smarter All Day Long
• Flow: The Psychology of Optimal Experience
• Succeed: How We Can Reach Our Goals