books

Book Summary: The Effective Engineer by Edmond Lau (I)

author

Luis Paredes

published

May 5, 2023

In the age of AI, being productive is more important than ever, and if you're looking to improve in this area as a software engineer or software manager, Edmond Lau's book The Effective Engineer is a great place to find insights on how to become more productive in a software development role.

Edmond Lau is a former software engineer at Google and Quora, and in his book, he provides practical advice on how to leverage your efforts in software engineering to make a disproportionate and meaningful impact.

In this two-part series, I'll examine the most useful insights from each chapter of the book, covering topics such as time management, prioritization, communication, and technical skills.

Whether you're a new software engineer just starting out, or an experienced engineer looking to improve your effectiveness, I hope the two installments of the series will provide you with actionable tips and strategies to help you succeed in your career.

1. Focus on High-Leverage Activities

To increase your impact as a software engineer, it's important to focus on high-leverage activities. This means directing your energy towards activities that have a higher impact, rather than easy wins.

The leverage of an activity is determined by the value or impact produced per time invested, which can be increased by:

  • reducing the time it takes to complete an activity,
  • increasing the output of an activity, or
  • shifting to higher-leverage activities.

Another way to think of leverage activities is by applying the Pareto Principle, which states that roughly 80% of the impact is produced by about 20% of the work.

Prioritizing work is essential for software engineers, since regardless of how good you are at what you do, you're bound to face situations where there is more work to do than time available, so you'll have to prioritize to increase the impact of your activities.

In summary, adopting a systematic approach to identify high-leverage activities and prioritizing accordingly is the first step towards becoming more productive.

2. Optimize for Learning

The second chapter emphasizes the importance of optimizing for learning to develop skills and knowledge that will compound over time. It's not just about effortlessly succeeding, but rather learning from challenges and failures. The earlier you start optimizing for learning, the more time your learning has to compound, and even small deltas in your learning rate make a big difference over the long run.

To optimize for learning, it's important to seek work environments that are conducive to learning and to surround yourself with potential teachers and mentors. Carve out about 20% of the time at work to learn. This time could be spent mastering your stack, participating in design discussions, and working on mini-projects (e.g.: a script that automates part of your work, an internal tool, etc.).

It's also beneficial to invest in learning outside of the workplace. This can include learning new programming languages and frameworks, investing in skills in high demand, reading books, attending talks and conferences, building a strong network of relationships, following bloggers who teach (like myself 😉), and pursuing side projects.

The more you invest in your learning, the more high-leverage opportunities you'll create for yourself in the future.

3. Prioritize Regularly

Chapter 3 emphasizes the importance of prioritizing regularly in order to maximize productivity.It's important to continually ask if there is something else that could be higher-leverage and to focus on what directly produces value. Effort should be proportional to expected impact, and it's important to defer or ignore tasks that don't contribute to productivity.

The chapter highlights two simple heuristics for identifying high-leverage tasks (so that you can prioritized them after being identified):

  • focusing on what directly produces value and
  • focusing on the important and non-urgent.

Other useful tips from the chapter that are not directly related to prioritization:

  • Make use of checklists to help reduce errors, mimicking the way pilots and surgeons make sure they don't forget any of the important items for each activity they perform
  • Protect your maker's schedule by limiting meetings and blocking off chunks of time can help with productivity
  • Limit the amount of work in progress to help prevent constant context switching
  • And last, but certainly not least, fight procrastination with if-then plans can help fill gaps in your maker's schedule, e.g.: If I get 20 free minutes, then I'll read an article on X topic (instead of wasting those 20 min on TikTok 😜)

4. Invest in Iteration Speed

Investing in iteration speed is crucial for engineering teams to deliver software at scale. By investing in tools and processes that allow for continuous deployment, teams can increase their speed of delivery while ensuring that their code is stable and reliable.

Another important aspect of investing in iteration speed is the ability to roll back changes easily in case something goes wrong. By deploying changes in smaller batches and testing them thoroughly before release, it becomes easier to identify and debug problems if they do arise. Additionally, gating large features behind configuration flags allows teams to selectively enable them for internal team members, beta users, or a fraction of production traffic until the feature is ready for general release.

To invest in time-saving tools, we should start small: find a single area where a tool could save time, build it, demonstrate its value and repeat. We should also focus on shortening debugging and validation loops by mastering the programming environment and automating common tasks.

It's also important to proactively try to fix processes inside our sphere of influence, and work around areas outside of our control. This may involve communicating more effectively with stakeholders, or taking on additional responsibilities to ensure that our work is not blocked by others.

Finally, we should not defer approvals until the end of a project, and should instead seek out early feedback and validation from stakeholders to ensure that our work is on track and aligned with the broader goals of the organization.

5. Measure What You Want to Improve

This section of the book delves into the significance of measuring progress and utilizing metrics to drive improvement. The main idea is that without measuring what you want to improve, it becomes difficult to assess whether the changes you've made have had a positive or negative impact.

Different metrics can incentivize different behaviors, therefore it's essential to choose the right metric to measure. For instance, tracking hours worked per week might encourage longer hours, but tracking productivity per week might encourage greater efficiency (being busy is not the same as being productive). Similarly, measuring click-through rates might optimize for short clicks, but measuring long click-through rates might optimize for relevance (a user may leave the page quickly even if he clicks on the link that leads to the page).

The chapter stresses the importance of instrumenting everything to comprehend what's happening. Successful tech companies build pilot-like flight instruments, making it easy for engineers to measure, monitor, and visualize system behavior. Some of the useful numbers to track are:

  • the number of registered users, weekly active users, and monthly users
  • the number of requests per second
  • the amount and total capacity of data stored
  • the amount of data written and accessed daily
  • the number of servers needed to support a given service
  • the throughput of different services or endpoints
  • the growth rate of traffic
  • the average page load time
  • the distribution of traffic across different parts of a product
  • the distribution of traffic across web browsers, mobile devices, and operating system versions

Finally, you should keep a healthy level of skepticism when reading the data you collect, since the collection mechanism may also contain bugs. Always ask yourself whether the data you see makes sense and compute critical metrics using different approaches so you can cross check the results.

Conclusion

As you finish up the first five chapters of The Effective Engineer, you have likely gleaned some valuable insights on how to optimize your productivity as a software engineer. However, there is still much more to learn from this influential book.

In part two of this series, we will continue to explore the remaining chapters and uncover even more key lessons. So, stay tuned for the next installment, and continue your journey towards becoming a more effective and impactful engineer.