Book of the Week: The Effective Engineer
22 Aug 2015
This week, I read Edmond Lau’s The Effective Engineer since one of my coworkers had a copy of the book and suggested I read it. It’s a book about how to be a more effective engineer. By giving me this book to read, my coworker is implying I’m not effective. What a jerk. As I read the book, I’ve noticed that the author references a lot of other books that I have read. If you’re in silicon valley, there is an implicit school of thought and body of knowledge that comes from books and practices being spread around. You don’t really get this by staying at a company. Edmond migrated around a few companies and interviewed a bunch of people to acquire this body of knowledge. This makes this book a good starting point for a new engineer coming into silicon valley, but seems kind of pedestrian to veterans. But it is still good to be reminded of best practices. If you don’t follow best practices, you wind up with something like burning $292 million for healthcare.gov. Although that also was due to consulting firms milking the government for money. Alternatively, you could have gotten a few unicorns from a venture fund with that money. Leverage The book is about leverage and creating as much value as you can as an engineer. Leverage = Impact Produced / Time Invested. You can increase value you product per unit time by:
- Reducing time it takes to complete activity
- Increasing output of activity
- Switching to higher leverage activity
Spend less time doing crap that doesn’t matter. To spend time on things that do matter, you need to step back and take time to prioritize things. Learning
Give me six hours to chop down a tree and I will spend the first four sharpening the axe. - Abraham Lincoln
One chapter of the book says you should optimize for learning. The better equipped you are, the easier it will be to solve problems. One thing other people liked about this book was that it provided concrete examples of things you could do instead of being abstract. Edmond suggests the following to help you optimize for learning:
- Learn new programming languages and frameworks
- Invest in skills that are in high demand
- Read books
- Join a discussion group
- Attend talks, conferences, and meetups
- Build and maintain a strong network of friendships
- Follow bloggers who teach
- Write to teach
- Tinker on side projects
- Pursue what you love
Tools and Automation
If you have to do something manually more than twice, then write a tool for the third time. - Raffi Krikorian, Twitter VP
The key to making tools is to allow other people to help themselves without asking you to do things. The lazier you can be and the less stuff you need to do, the better. An engineer should build a tool, so that task becomes someone else’s job. Every little distraction that comes prevents you from spending focused time on creative work. Having good documentation, you can point people to will deflect questions. Making things self-serve will free up your time. Make a fishing pole and give it to people, so you can stop giving them fish. Automation also alleviates burdens. Things just happen, so you don’t need to worry about it. Things should keep working while you’re on vacation. Here are some activities that automation can help.
- Validating that piece of code, interaction or system behaves as expected
- Extracting, transforming, and summarizing data
- Detecting spikes in error rates
- Building and deploying software to new machines
- Capturing and restoring database snapshots
- Periodically running batch computations
- Restarting a web service
- Checking code to ensure it conforms to style guidelines
- Training a machine learning model
- Managing user accounts or user data
- Adding or removing a service to or from a group of services.
Estimates As you become more involved in project management, you need to be able to provide good estimates. Accurate estimates are better than optimistic estimates. The sooner you know you are going to slip on something, the better since that will allow time to plan around it. Here are some concrete strategies for project estimates.
- Decompose project into granular tasks
- Estimate based on how long tasks will take, not how long you or someone else wants them to take
- Think of estimates as probability distributions
- Let the person doing the task make the estimate
- Beware of anchoring bias
- Use multiple approaches to estimate same task
- Validate estimates against historical data
- Beware of mythical man-month.
- Use timeboxing to constrain task that can grow in scope.
- Allow others to challenge estimate
Great Engineering Culture
The higher you climb the engineering ladder, the more your effectiveness will be measured not by your individual contributions but your impact on the people around you.
As you move up the ladder, people turn to you for technical expertise, design decisions and guidance. It is not about sitting down and writing fast, scalable code. It is about helping other people write fast, scalable code. Focus on helping your team achieve goals becomes your job. This means you need to invest time doing nontechnical things like having meetings and meetings about meetings, giving talks, mentoring, sitting on committees, etc. For you to succeed in the organization, you must make other people succeed. Which is why it is important to hire people who can succeed, because your success is measured by them.
- Optimize for iteration speed.
- Push relentlessly towards automation.
- Build the right software abstraction.
- Focus on high code quality by using code reviews.
- Maintain a respectful work environment.
- Build shared ownership of code.
- Invest in automated testing.
- Allow experimentation time, either through 20% time or hackathons.
- Foster a culture of learning and continuous improvement.
- Hire the best.