21 Lessons From 14 Years at Google

Alternative Titles

• What 14 Years at Google Taught Me About Everything Except Code
• The Senior Engineer Skills No One Teaches You in Bootcamp
• Why Winning Technical Arguments Quietly Kills Your Projects
• Clarity Is Seniority: A Googler's Field Notes on Compounding Careers

Key Takeaways

• Great engineers work backwards from user problems, not from favored technologies. Starting with a solution breeds complexity built to justify itself; deep problem understanding usually reveals a simpler answer than anyone expected.
• Being right is cheap — getting to right *together* is the real skill. Winning every technical debate accumulates silent resentment that later surfaces as 'mysterious execution issues.' Hold strong opinions weakly, because decisions made under uncertainty shouldn't be welded to identity.
• Bias toward action: you can edit a bad page, not a blank one. Ship ugly prototypes, messy drafts, embarrassing MVPs — one week of real feedback beats a month of theoretical debate. Momentum creates clarity; analysis paralysis creates nothing.
• Clarity beats cleverness every time. Code is a strategy memo to strangers who will maintain it at 2am during an outage — optimize for their comprehension, not your elegance. Senior engineers trade cleverness for clarity as a discipline.
• Treat novelty as a loan repaid in outages, hiring cost, and cognitive overhead. Spend one 'innovation token' per materially non-standard choice; default to boring tech with known failure modes, and innovate only where you're uniquely paid to.
• Your code doesn't advocate for you — people do. Decisions happen in meetings you're not in, via summaries you didn't write; if no one can articulate your impact when you're absent, it's effectively optional. Make the value chain legible.
• The best code is code you never write. Deletion often improves systems more than addition, yet nobody gets promoted for it. Before building, seriously ask 'what happens if we just… didn't?' — sometimes 'nothing bad' is the answer.
• At scale, even your bugs have users. People scrape your API, automate your quirks, cache your bugs — so compatibility is product, not maintenance. Most 'API design' is actually API retirement: design deprecations as migrations with time, tooling, and empathy.
• Most 'slow' teams are misaligned, not lazy. Coordination costs grow geometrically as teams multiply, so the real bottleneck is people building the wrong things or incompatible things. Senior engineers spend more time clarifying direction, interfaces, and priorities than writing code faster.
• Abstractions don't remove complexity — they relocate it to your on-call shift. Every abstraction bets you won't need to understand what's underneath; something always leaks. Keep learning lower-level layers out of respect for the 3am moment when the stack fails.
• Writing forces clarity and is a selfish learning hack. Explaining a concept — in docs, talks, reviews, or to an AI — exposes gaps in your understanding. Where you stumble is where your model is shallow; teaching debugs your own mental models.
• Glue work (docs, onboarding, coordination) is priceless but invisible — a dangerous career combo. Done unconsciously, it stalls trajectory and burns you out. Timebox it, rotate it, turn it into artifacts, and make it legible as deliberate impact rather than personality.
• Goodhart bites every metric: when a measure becomes a target, it stops measuring. Track lines of code and you get more lines; track velocity and estimates inflate. The senior move is pairing every metric with a counter-metric (speed with quality/risk) and interpreting trends, not worshiping thresholds.
• Saying 'I don't know' creates psychological safety, not weakness. When leaders admit uncertainty, juniors stop pretending to understand, assumptions get challenged, and hidden problems surface before they explode. Model curiosity to get a team that actually learns.
• Most performance wins come from removing work, not adding cleverness. Caching, parallelism, and smarter algorithms matter less than asking 'what are we computing that we don't need?' The fastest code is code that never runs — question whether the work should exist before optimizing it.
• Process should reduce uncertainty, not create paper trails. If you can't explain how a process lowers risk or raises clarity, it's bureaucratic theater — overhead that exists to assign blame. When documenting work takes longer than doing it, something is deeply wrong.
• Careers compound when learning creates new options, not just new trivia. There are no shortcuts to expertise — only deliberate practice over years — but writing for clarity, building reusable primitives, and turning scar tissue into playbooks compounds. Treat career as compound interest, not lottery tickets.

Readwise Summary (short)