Book Report - The Effective Engineer
Introduction
The Effective Engineer, by Edmond Lau and published by The Effective Bookshelf, is a book focused mainly on leverage, and using your time as a developer to achieve the largest amount of that leverage possible. It covers quite a few techniques and practices that Edmond Lau discovered and improved upon at his time at companies such as Google and Quora. It has a website at http://www.effectiveengineer.com/ but actually I wouldn’t really recommend that site as it looks very self-help-y and not really in the spirit of the actual advice of the book in my opinion.
It looks like this:
This blog post is part of my “Book Report” series, where while reading a book I’ve been recommended I’ll take informal notes on each chapter and then type them up at the end as a blog post I can reread later as both a refresher and a place to note down my thoughts on the book in general.
Chapter Breakdown
Part 1 - Adopt the Right Mindsets
Chapter 1 - Focus on High-Leverage Activities
This chapter introduces leverage as a concept and focuses on productivity from the standpoint of a whole business as opposed to a single person. I got the feeling it was mainly setup for the rest of the book, though it did have a few small points that resonated with me, such as how managers get more done since their tools are other developers.
Chapter 2 - Optimize for Learning
The focus this time was on compound interest as a comparison to compound learning; trying to convey the fact that the earlier you learn something, the more benefit you get from it over time, which is a really useful concept to take on board. It also mentions Luck Surface Area in a roundabout way and not directly, but conveys a lot of the same viewpoints.
Chapter 3 - Prioritize Regularly
The title really sums this part up, essentially the idea is that you want to discern what the higher leverage tasks are, and prioritise those. This on the face of it doesn’t sound too revolutionary, but the book also goes through common productivity hacks, a lot of which are shared with the excellent getting things done for hackers and also mentions things like pomodoro. Personally I still find it really hard to have the kind of discipline for tackling tasks that the author does, but the techniques here definitely help.
Part 2 - Execute, Execute, Execute
Chapter 4 - Invest in Iteration Speed
This in my opinion is where the book really starts to approach everyday tasks in a software engineering manner, focusing on things such as iteration loops, identifying bottlenecks and automating things. As such this makes for a really good read, in particular the point of trying to quantify and measure time to better identify optimisations is great.
Chapter 5 - Measure What You Want to Improve
Again this takes a very engineering-focused approach to everyday tasks, whether strictly work related or not. As a result you get some really decent advice that you can pretty much apply to anything, such as “collect as much data as possible” which might sound obvious when talking about a system or a website, but not as obvious when talking about learning things or work tasks themselves.
The key takeaway for me from this chapter was the phrase “Is there some way to measure what I’m doing currently?”
Chapter 6 - Validate Your Ideas Early and Often
This was the only chapter I didn’t find too useful, potentially because of the difference in what I work on to the subject matter. I did find that this chapter (and only this chapter, which is quite an achievement!) really does focus on a startup mindset, with a view to founding a startup. That’s great and all but not really applicable to most people outside of silicon valley. It did still have a few points that were great though, such as stressing the importance of feedback loops.
Chapter 7 - Improve Your Project Estimation Skills
Estimating is a subject people have written tomes about and discussed at length, so really this chapter is just a brief overview of some of the more in-depth resources out there, but it does bring some good advice to the table, such as:
- Well defined scope is important
- Front-load the scariest and hardest tasks
- Incremental rewrites are probably the only rewrites worth doing
Part 3 - Build Long-Term Value
Chapter 8 - Balance Quality With Pragmatism
Another very technically focused chapter, covering things such as the importance of good API design and other similar points. This was a good chapter but didn’t really have anything revolutionary for me, potentially just because of how much subject matter there already is out there on things such as technical debt.
Chapter 9 - Minimize Operational Burden
This chapter generally just has a lot of really good tips on technical situations, things like “Scripts should be idempotent or transactional” and “Systems should fail fast and decisively” which are all really good advice. It doesn’t have as much of a cognitive thread as a lot of the other chapters but it does have a wealth of really good advice. In particular the section on planning for failure is great.
Chapter 10 - Invest in Your Team’s Growth
Finally, this chapter is a lot more focused on managerial tasks than technical, covering things such as the importance of hiring, which is a subject I agree with quite a bit (this blog post in particular has some really good thoughts on hiring) and also covers a lot of things such as trying to share ownership and the troubles this can have.
Overall Thoughts
Overall I’d really recommend The Effective Engineer, I really see it as a great, more efficiency focused version of The Pragmatic Programmer. It’s not too heavy a read either, so it’s very easy to dip in for 30 mins and cover a chapter.