🔗 21 Lessons from 14 Years at Google
There’s probably a limit to how many “lessons” blog posts one should read but, every once in a while, they’re helpful. Many of these resonate with me after a similar amount of time in research and academia.
Metadata
- Author: Addy Osmani
- Category: rss
- URL: www.oreilly.com/radar/21-…
Highlights
The “best tool for the job” is often the “least-worst tool across many jobs”—because operating a zoo becomes the real tax.
- Abstractions don’t remove complexity. They move it to the day you’re on call. Note: “Every augmentation is an amputation” Senior engineers keep learning “lower level” things even as stacks get higher. Not out of nostalgia but out of respect for the moment when the abstraction fails and you’re alone with the system at 3am. Use your stack.
Teaching is debugging your own mental models.
- If you win every debate, you’re probably accumulating silent resistance.
Model curiosity, and you get a team that actually learns.
Your job isn’t forever, but your network is. Approach it with curiosity and generosity, not transactional hustle.
Deleting unnecessary work is almost always more impactful than doing necessary work faster. The fastest code is code that never runs.
The engineer who treats their career as compound interest, not lottery tickets, tends to end up much further ahead.
The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected.
First do it, then do it right, then do it better.