The Effective Engineer by Edmond Lau

Review & Summary

Review

I recommend this book, especially to Junior — Mid-level Software Engineer. The Effective Engineer focuses on guiding Software Engineers to maximize their impact through the framework called Leverage. Throughout the book, Edmond shares about the list of “high leverage” activities which comes from his own experiences and the interviews he has done with other technology companies, though mostly in Silicon Valley. Some of these high leverage activities includes collecting early feedbacks, measuring the right metrics, continuous deployment, standardizing best practices, and automation.

The book covers a wide range of topics from Productivity, Project Management, Time Management, etc. But the book did not go into much details on the implementation of the ideas and advices. After all, each of those topics warrants another book for itself. If readers are interested to get more details into any specific topic, the Appendix contained a list of 10 books and blogs that Lau recommends.

I wish that Lau also includes stories and interviews from other technology companies outside the Silicon Valley. It would be interesting to see how effective his idea of Leverage is anywhere else.

Quote from the Book:

Effective engineers aren’t the ones trying to get more things done by working more hours. They’re the ones who get things done efficiently — and who focus their limited time on the tasks that produce the most value. To be effective engineers, we need to be able to identify which activities produce more impact with smaller time investments. Not all work is created equal. Not all efforts, however well-intentioned, translate into impact.

Summary of the Effective Engineer

Introducing the Right Mindsets: Leverage, Optimize for Learning, and Prioritization

The book starts with introducing the concept of Leverage.

Leverage is the value, or impact, produced per time invested.

To improve effectiveness, every Software Engineer should ask himself or herself these 3 questions:
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 that I could spend my time on that would produce more value?

To shorten the invested time 0r increase the value produced will require different mindsets and approaches to how we accomplish our work . The first mindset is to embrace the “Growth Mindset”: a belief that people can cultivate and grow their intelligence and skills through effort. Thus, we should find learning opportunities inside and outside our workplace. As we prioritize learning and improve our skills, we will find better and faster way of doing things.

The other mindset that Lau advocates for is prioritization. Different works produce different values. So, as works keep piling on, we must choose wisely. More than just responding to the urgent tasks, Lau reminds us to focus on the important and non-urgent works that have significant long term value but often get neglected. The book also offers few productivity tips, such as managing your to-dos, reducing context switches, and making if-then plans to combat procrastination.

Invest in Iteration Speed

Improving iteration speed is necessary to be more effective. After all, the faster we can finish our work, the more works can get done within a time period. So, what kind of activities that can help us shorten our iteration speed?

  1. Master the fundamentals of our craft
    Be knowledgable and proficient with the development environment.
  2. Invest in tooling
    Choose the right tools and softwares to help make our development cycle faster.
  3. Take a holistic view of the whole workflow
    Is there any bottleneck in your end-to-end workflow? Most often the bottleneck comes from process constraint or people constraint. Ex: decision requires approval from certain people or dependency on other team.
The faster you can iterate, the more you can learn.

Measure What You Want to Improve

How would you know what types of effort are well spent? Without measuring the right metrics, we would neither know the value of our works nor how to prioritize well. Good metrics help us focus on the right things, alert us against future regression, and eventually help us evaluating our effectiveness over time.

When deciding which metrics to use, choose ones that 1) maximize impact, 2) are actionable, and 3) are responsive yet robust.

Validate Your Ideas Early and Often

The purpose of validating ideas early and often is to help us get the right things done. Reaching out to people to get feedbacks on our works might seem to slow us down. But, doing so can prevent us from putting hours and hours of work, only to find out later that we have made a wrong decision or a wrong assumption. Instead, we should approach a problem iteratively to reduce wasted effort. Each iteration provides opportunities to validate new ideas. Iterate quickly to learn quickly.

As software engineers, here are few things that we can do:

  • Request code review and commit early and iteratively.
  • Discuss the API design or interface or design document before coding it.
  • Reduce the risk of large implementations by using small validations. Invest a little extra effort to figure out if the rest of your plan is possible and worth doing.
  • Solicit buy-in and regular feedback, especially in new, high-risk projects.
  • Use A/B testing to validate your product hypotheses.

Improve Your Project Estimation Skill

Having a good project estimation skill will help us accurately calculate the “time invested” for each project. Our goal is to always work on the project with the highest leverage, big impact with small time investment. If our project estimation skill is bad, then the leverage point that we assign to each project is inaccurate. Consequently, we might end up not choosing to work on the project with the highest leverage. Edmond suggestions on how to improve your project estimation skill:

  • Don’t let a desired target dictate the estimates. Instead, these estimates should be used as an input to decide whether delivering a set of features by a certain date is feasible. If it is not, they should lead to a conversation about whether to change the feature set or the delivery date.
  • Allow buffer room for the unknown in the schedule. Take into account competing work obligations, holidays, illnesses, etc. The longer a project, the higher the probability that some of these will occur.
  • Define measurable milestones. Clear milestones can alert us as to whether we’re on track or falling behind. Use them as opportunities to revise our estimates.
  • Do the riskiest tasks first. Reduce variance in our estimates and risk in our project by exploring the unknown early on.

Balance Quality with Pragmatism

Balancing quality with pragmatism is little bit like an art. On one hand, we want our work to be a master piece. On the other hand, we are limited on time and other resources to finish our work.

Ultimately, software quality boils down to a matter of tradeoffs, and there’s no one universal rule for how to do things. High software quality enables organizations to scale and increases the rate at which engineers can produce value, and underinvesting in quality can hamper your ability to move quickly. On the other hand, it’s also possible to be overly dogmatic about code reviews, standardization, and test coverage — to the point where the processes provide diminishing returns on quality and actually reduce your effectiveness.

Key Takeaways from this chapter:

  • Establish a Culture of Reviewing Code
    Find the right balance between code reviews and tooling to trade off code quality and development speed. Ex: code review approval is required for the crucial or fragile part of the software, but not on some special features for niche customers.
  • Build a Suite of Automated Unit and Integration Test
    Testing every piece of codes can be too time consuming. We should focus on the pieces of codes that are regularly used and developed.
  • Manage Technical Debt
    Focus on debt that crippling our work the most.

Minimize Operational Burden

We are not done when when we deploy that new feature to production. We still need to maintain it, monitor the traffic, fix any bug that surfaces, etc. Software and system maintenance are something that all engineers have to deal with continuously. Thus, minimizing operational burden is crucial because we can’t accomplish much if a lot of our time is used on maintaining and fixing the system.

Key Takeaways from this chapter:

  • Be Careful of the “Shiny New Things” Syndrome
    Technology keeps evolving, and almost every few months we will hear about this new technology or framework that promises to solve all our problems. While experimenting with the new technology is exciting, think twice before introducing it to the production system. Do other team members have experience with it or can they easily pick it up? Does the system work well under high load? How easy it is to monitor it, scale it it, etc?
  • Do the simple thing first. 
    As the product grows, so does it’s complexity. The more complex the system is, the harder it is to maintain. We should always ask ourselves, “What’s the simplest solution that can get the job done without incurring high cost of operational burden?” Simpler systems are easier to understand, extend, and maintain.
  • Build Systems to Fail Fast
    Surfacing problematic issues sooner can help us reduce the time we spend on debugging and tracing back production logs.
  • Automate Mechanics Over Decision-making. 
    Aggressively automate manual tasks to save time. We can do that by simply writing a script or building an automation program. At the same time, think twice before trying to automate decision-making, which tends to be hard to get correct.
  • Plan and practice failure modes. 
    Building confidence in your ability to recover lets you proceed more boldly.

Invest in Your Team’s Growth

Engineering is not an individual sport, it is a team sport. The people and the team that we work with will influence our own effectiveness. The team culture, the working environment, and the development process are just few examples of what can hinder or accelerate our work. Thus, improving the team’s effectiveness will also influence our own effectiveness.

Key Takeaways from this chapter:

  • Review and document collective wisdom. 
    Reflect on projects with team members, learn what worked and what didn’t work, and document and share the lessons so that valuable wisdom does not get lost. This will also benefit a new team member who joins later on.
  • Invest in on-boarding and mentoring. 
    The more quickly a new team member can ramp up, the more effective the team will be.
  • Build shared ownership of code. 
    Prevent a development bottleneck by having more than one expert for each project.
  • Create a great engineering culture. 
    This will help the team to be more productive, streamline decisions, and recruit other strong engineers.

End

One thing to remember:

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.