Book Notes: 'The Effective Engineer' by Edmond Lau

The Effective Engineer by Edmond Lau is a book about how to be more effective within your organization. Note that there is a difference between “effective” and “efficient”. Maximizing “effectiveness” requires you to make sure that you’re working on high leverage activities. It doesn’t matter how efficient you are at completing tasks if the tasks don’t product business value.

I thought the book was good, and there wasn’t really anything that I took issue with. Some parts of the book are probably obvious to people with work experience. I would definitely recommend the book, especially to engineers that are frustrated by the impact they’re delivering to their teams.

Here are my notes:

What does it mean to be effective?

Which activities should you focus on?

Optimize for learning

I want to point out that I find the (common) example of learning as compound interest to be…shaky. I’m not convinced that the vertical axis (“knowledge”, “value”, etc.) is a compelling metric. It isn’t clear to me that the model accurately describes the phenomenon.

I have “known” many things throughout my life that I have completely forgotten about - my answers for “how does the spanning tree protocol work?” would be very different today than 10 years ago.

That said, I think it’s a decent heuristic and motivator for people to learn more. I suppose that’s what counts.


There are no shortage of things to focus on, so how do you choose? Focus on high leverage activities by:

  1. Identifying which tasks directly produce value
  2. Focus on tasks that are important, but not urgent

Work on tasks that directly produce value

“Activity is not necessarily production” - Yishan Wong

“Value” can be measured in a variety of ways: user growth, sales, business metrics, etc.

Always consider opportunity cost. Even though a task might produce value, doing it means not doing some other task, which may produce more.

Focus on the important and non-urgent

Things that are important but non-urgent:

If you only ever focus on fire-fighting crises, you may miss out on long-term opportunities that aren’t pressing. You can also take note of which crises frequently come up, and see if they’re symptoms of a larger problem that needs to be solved.

Protect your maker’s schedule. Limit the amount of things you’re working on concurrently. Make a habit of prioritization.

Iteration Speed

Continuous deployment is an example of how you can improve iteration speed by reducing overhead.

“Move fast and break things”

My note: MFABT is integral to delivering value:

Invest in time-saving tools

I personally think this is very important, and I think “tool” can take on a range of meanings. Writing scripts to do tedious tasks is an obvious example, as long as it’s worth it. I think learning the vim way of editing text has been a massive productivity boost. I say “vim way” because I mostly use vim plugins inside of IDEs. Making an “IDE” of Frankenstein’d vim plugins has never worked out well for me. Being able to nimbly edit text, however, pays off every time I need to write anything on a computer. I even use vim shortcuts to navigate web pages.

Lau’s tips:

Measure What You Want to Improve

Choosing what to measure helps you focus on the right things. It’s helpful to identify metrics that are directly related to the work you’re doing, to ensure that your efforts have the impact you expected.

Metrics can also:

Pick the right metric - some can actually harm your output if you optimize for them:

The metrics you choose will influence the behavior you take.

Be skeptical about data integrity. Using iffy metrics can win debates, but hurt the organization in the longrun.

Validate Your Ideas Early and Often

It’s important to validate ideas early to make sure you’re working on the right things. No one likes working on something for 6 months only to find out that it doesn’t even solve the problem - because no one actually talked to the people with the problem. Get feedback as early as possible.

MVPs are a common way to do this. MVPs are covered extensively in other books and blogs. Continuously validate changes with A/B testing.

Beware the one-person team

Working for too long without feedback can cause a number of problems:

Avoid these risks by:

Improving Project Estimation Skills

Balancing Quality with Pragmatism

Establish a sustainable code review process. Benefits of code reviews:

These benefits can come at a tradeoff of iteration speed.

Manage complexity by choosing the appropriate abstraction (sounds easy when put that way). Choosing a bad abstraction can seriously hamper development velocity.

Automated tests and strategically paying off technical debt can have an outsized impact in the longrun.

Minimize Operational Burden

The first part of this chapter is basically saying - choose boring tech.

Automate mechanical tasks, like:

This list is pretty broad, but it’s helpful to give people ideas.

Make batch processes idempotent

By making them idempotent, you can deal with failures (network, application, etc.) more gracefully.

If you can’t make it idempotent, try to make it reentrant (I would like to see an example of this).

Idempotent batch processing also lets you surface failures appropriately. Lau gives an example of running a check every 60 seconds, instead of 5+ minutes, and only raising the issue if the error repeats on subsequent tries.

Plan and practice failure modes

Netflix Chaos Monkey example

Invest in Your Team’s Growth