Software Engineering at Google
I picked up Software Engineering at Google, expecting a few good ideas scattered across a lot of filler. That’s not what I got. The book is dense — it’s an O’Reilly title, so different chapters will hit differently depending on where you sit and what problems you’re solving — but the sections that landed for me landed hard. Here’s what I underlined.
Leadership
The thing about admitting mistakes: most leaders are afraid it makes them look weak. The opposite is true. Teams notice when you own it, and they trust you more for it.
On conflict — trace almost any interpersonal blowup back far enough, and you’ll find a failure of humility, respect, or trust. Usually all three.
The psychological safety point is one I’ve repeated to almost every team I’ve led: you cannot build a learning culture if people are afraid to say “I don’t know.” Full stop.
My favorite line in the book: “Sometimes you get to be the tooth fairy, other times you have to be the dentist.” That one’s going on a sticky note.
Two questions I now ask myself regularly about delegation:
- What can I do that nobody else on my team can do?
- What am I holding onto that I should be letting go of?
The framework for leading at scale boils down to: always be deciding, always be leaving. Identify the trade-offs, make the call, then get out of the way so your team can own it.
Testing
“If you liked it, you should have put a CI test on it.” The Beyoncé Rule. I’m not sure I can improve on that.
Scalability
Jevons Paradox: make a resource cheaper to use and people use more of it. Every infrastructure team I’ve worked with has been bitten by this. Efficiency doesn’t reduce demand — it creates it.
Maintainability
Hyrum’s Law stopped me cold:
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
If you’ve shipped anything at scale, you’ve lived this. Users don’t read the contract. They observe behavior and build on it. Whatever your system does — not what you say it does — becomes the API.
The Google joke in the same chapter: there are two ways to do anything — the way that’s deprecated and the way that’s not ready yet. If that doesn’t resonate with you, you haven’t shipped enough software.
Productivity
Four questions worth asking before you instrument anything:
- What result are you expecting, and why?
- If the data supports that result, what will you actually do with it?
- If you get a negative result, will you act on it — or explain it away?
- Who owns the decision, and when do they make it?
The Goal/Signal/Metric distinction is useful: a goal is what you want, a signal is something that would tell you you’re getting there, and a metric is a measurable proxy for that signal. Most teams skip straight to metrics and then wonder why their numbers are green and their product is struggling.
Douglas Adams, on deadlines: “I love deadlines. I like the whooshing sound they make as they fly by.” Timeless.
Culture
Google’s “Googleyness” rubric is worth stealing wholesale: thrives in ambiguity, values feedback, challenges the status quo, puts the user first, cares about the team, and does the right thing. I’d hire for that list at any company.
Usability
Design for the person who will have the most difficulty using your product. Everything else is optimization.
Leave a Reply