This book won’t be a substitute for mindful reflection.
Most books aren’t.
This boils down to a few simple but difficult lessons:
- Maximize expected utility (called leverage in the book).
- Constantly check to see if you’re bullshitting yourself.
If you can make both of them habits, you’ll find this book really obvious.
Foreword
Don’t Solve Problems That Don’t Need Solving, AKA Think
Whenever we would encounter a challenging technical problem, I would ask “How should we do this?” Paul would respond, often obnoxiously, “Why do we need to do it at all?” Instead of trying to solve impossible problems, he would more often challenge the assumptions so we could simply work around them. At times, it almost seemed like Paul was lazy—given any sufficiently hard project, Paul would question the purpose of the project. But he was almost always right. Unless the project was destined to make or break our nascent company, why spend our precious engineering resources on it?
Chapter 1: Focus On High-Leverage Activities
This is an obvious lesson that’s only useful if you constantly repeat it and make it a habit. It’s worth it, though, since it’s important pretty much by definition.
The simple formula given is a useful way to see what to do next, since it shows how to measure leverage. You can improve your leverage in 2 ways:
- Have more impact
- Increase the impact of what you’re already doing
- Do something else that’s higher-impact
- Take less time to do something
Don’t confuse high-leverage activities with easy wins, however. Just as a lever lets you apply a small amount of force over a long distance to generate a much larger force, so too do many high-leverage activities require consistent applications of effort over long time periods to achieve high impact.
When engineers asked him how the company would ensure that the people being hired were strong engineers, Wong would tell them that this was their job.
Yishan Wong and Bobby Johnson both have solid advice in this book (and in general). If one of them wrote this book, I’d have read it way sooner.
chapter 2: Optimize for Learning
If you truly internalize the importance of exponential growth, this chapter is really tedious. If you haven’t, then it’s really interesting.
How boring you find this chapter is a good indication of your intuition about exponential curves.
If you haven’t seen this before, check out the rule of 72.
Chapter 3: Prioritize Regularly
This book has an unstated but important recurring theme: process will make or break you, and not even really in the long run. For a hint of what I mean, see Wesley’s blog post.
In fact, let’s call it Lesson 3:
- Process is everything in an organization.
This chapter boils down to: make a personal process for figuring out what to do. The rest is a bunch of details about how.
One point I liked was to focus on important but non-urgent tasks. Avoiding fire drills is not just good for your health, it focuses you on what will make you successful in the long run.
Chapter 4: Invest In Iteration Speed
Short iteration cycles make it easier to tell if you’re bullshitting yourself, or are just wrong.
Tools are really important. People’s effectiveness is roughly fixed, averaged over an organization. So tools are your main way of boosting productivity.
Much like computers, the speed of a tool, if it’s fast enough, give quantity its own quality. John von Neumann said this years before, but I can’t find the quote, so I’ll quote Edmond:
Faster tools get used more often.
Second, faster tools can enable new development workflows that previously weren’t possible.
John Cook has a nice piece of advice about this. Prioritize mental energy over time.
The section titled Don’t Ignore Your Non-Engineering Bottlenecks should really be at the front, since often that’s much higher leverage, based on the number of dysfunctional organizations filled with smart people I’ve seen.
Chapter 5: Measure What You Want To Improve
This is essentially the problem of reward design in reinforcement leaning. It’s a hard problem, and this chapter is too general to have really concrete advice. Keep Lesson 2 in mind and don’t ignore that nagging feeling that something isn’t really right.
During my first five years at startups, I’ve gone through a few crunch periods where engineering managers pushed for 70-hour work weeks in the hopes of shipping a product faster. Not once have I come out of the experience thinking that it was the right decision for the team.
I like the military’s take on this: you don’t rise to the occasion, you fall to your training.
Another nice aphorism: proper preparation prevents poor performance.
If you’re at the stage of constant fire drill, your process is screwed and life sucks. You didn’t pay attention to Lesson 3.
Chapter 6: Validate Your Ideas Early And Often
Lesson 2.
Do you want to think you’re right or do you want to actually be right?
Act accordingly.
During my junior year at MIT, three friends and I participated in the MASLab robotics competition. We had to build a one-foot-tall self-driving robot that could navigate around a field and gather red balls. 13 The first skill we taught our robot was how to drive forward toward a target. Simple enough, we thought. Our initial program scanned for a red ball with the robot’s camera, turned the robot toward the target, and sent power to the motors until the robot reached its destination. Unfortunately, minor variations in the motor speed of the front and rear axles, differences in the tread of the tires, and slight bumps on the field surface all caused our simple-minded robot to drift off at an angle. The longer the path, the more these little errors compounded, and the less likely the robot was to reach the ball. We quickly realized that a more reliable approach was for the robot to move forward just a little bit, then re-check the camera and re-adjust the motors for errors in orientation, and repeat until it reached the target.
Should’ve used DAGGer bro. Admittedly, it hadn’t been invented yet.
Chapter 7: Improve Your Project Estimation Skills
Learn about the planning fallacy and reference classes. Take the median of the reference classes as the estimate. If no reference class can be thought of, ask someone else. If that fails, take your estimate and double it. Treat that as the minimum.
Schedules need slack or they’re brittle.
This is a great illustration of the importance of process.
Chapter 8: Balance Quality with Pragmatism
Just noticed that the book has drop caps. Don’t do them, they look terrible.
The chapter is essentially Lesson 1.
It talks a bit about making good abstractions, since they simplify engineering life a lot. One piece of advice I liked:
Good abstractions disentwine complex concepts into simpler ones
Bobby Johnson, a former Director of Engineering at Facebook, claims that “[Thinking in terms of] right and wrong … isn’t a very accurate or useful framework for viewing the world … Instead of right and wrong, I prefer to look at things in terms of works and doesn’t work. It brings more clarity and is more effective for making decisions.”
Chapter 9: Minimize Operational Burden
Features aren’t free.
During Instagram’s early years, Krieger explained, its team consisted of no more than five engineers. That scarcity led to focus. They couldn’t afford to engineer any solutions that would break frequently or require constant maintenance. Far and away, the most valuable lesson they learned was to minimize operational burden. Krieger operated like the chief of a small fire department: he knew that each additional feature and new system represented an extra house that the team needed to support—and possibly firefight. Development costs didn’t stop accruing at launch time; in fact, they were just starting to accumulate.
Chapter 10: Invest in Your Team’s Growth
This is from chapter 1, but really should be restated here:
When engineers asked him how the company would ensure that the people being hired were strong engineers, Wong would tell them that this was their job. And because hiring was a top priority, engineers didn’t skip interviews to do other work.
Yishan has an article that I think Edmond linked that nails this.
Sink or swim isn’t a great way of treating your employees. Paraphrasing Dan Luu, why do we make the first few months of an engineering job some kind of hazing ritual, instead of simply teaching people what they need to know to be good engineers?
If you’ve hired someone and they don’t cut it, either fire them or help them
Letting people sink leads to a bunch of corpses polluting the pool.
You get more credit than you deserve for being part of a successful company, and less credit than you deserve for being part of an unsuccessful company.
Making others more effective is super high-leverage, and fun for non-sociopaths.
Process is huge here too, from hiring to postmortems. Rational and ruthlessly methodical grinds the competition to dust.
Take a tip from the military here too and look at the classes of supply. Note how weapons are halfway down the list, below boring support stuff like antifreeze. Whatever the military’s other flaws, they get the importance of process.