alt Hacker NewsLessons from 14 years at Google
Comments
excellent article and appreciate the author sharing his perspective which is very valuable.
For me the main lesson is, don't let your ego develop from success. Any human is vulnerable to narcissism. It is an interesting phenomenon, where you can originate as a humble person who becomes successful, only to lose your great qualities, when your identity changes. With success you attract different people in your life who may be attracted only to your success and who don't have the stones to confront you on your bs.
Developing healthy self awareness comes from surrounding yourself with people that love you, but are not afraid to keep you honest if you do something out of character.
GREAT ARTICLE!
> 17. Your network outlasts every job you’ll ever have.
i mean, addy has literally been at google 14 years, i think internal network has outweighed the external one here
>Abstractions don’t remove complexity. They move it to the day you’re on call.
Damn that's a real one. Nothing like struggling through a bunch of indirection to figure out what the heck a clever abstraction was supposed to do
Seems like the author had lost his personality during that 14 years trying to appease the strange people at the top or figure out the allpermeating bs they force on people.
most generic advice oat
I don't believe any of this.
What a mediocre article. Its just enough for people to agree and nod and go "wow yeah true!!" while offering almost zero value to people who don't already agree. These are not useful to juniors. Yes, almost all of this is true and well said, but it offers no additional value. It's like a smell test: Show this article to engineers and those who disagree with lots of points should be given a senior mentor.
These points are really good, but they often miss context and further info and caveats. I would have liked if the Author just added a little bit more content.
Like, for example, the point about "Being right is cheap. Getting to right together is the real work". Yes, it's certainly true that a decision made in agreement is better than one that isn't. However, how do you get there? Does everyone else give up their (weakly held, according to the article) opinions? I would argue it should be acceptable for your opinions to hold, to be factually based, and still to not align with the final decision made. Any respectable engineer should be fine with this.
> Your code doesn’t advocate for you. People do.
It depends on how much code you output relative to others, for example, and how performance is measured, how much time is actually spent in meetings (and how much of that is wasted or could-have-been-an-email). I've been told at a previous job that the quality and amount of code I output made them reconsider their entire salary- and bonus-structure (and they did restructure it but by the time it went into effect I had gotten a better offer and left). I just had more programming experience than most other developers there (through open source and my own projects), even though I was junior to most of them. Your code can advocate for you, and so can your general output, your contributions, etc. It's not all politics in all companies, though I'm sure the author's point applies at FAANG.
Furthermore, I don't know if this point results in actionable advice for juniors, for example. To not bother writing good code? To not bother with doing the best you can? To not honing your skill and instead go to public speaking courses? I'm not sure.
Good-ish article, just not enough novel substance IMO, and reads a bit like AI slop.
Also choked on this:
> Colleagues often remark on Osmani’s humility and generosity despite his fame in the field.
lgtm
that was an amazing read
This feels somewhat hypocritical coming from Addy.
Addy Osmani plagiarized my code and 'apologized' years later by publishing an article on his website[1] that he has never linked to from his social media accounts.
I cannot accept his apology until he actually syndicates it with his followers.
Seems relevant to note this behavior in light of points "6. Your code doesn’t advocate for you. People do.", "7. The best code is the code you never had to write.", and "14. If you win every debate, you’re probably accumulating silent resistance."
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
[dead]
seems the real lesson would be to not spend 14 years at google
Thought occurred to me to throw this at ChatGPT 5.2:
Given the article at https://addyosmani.com/blog/21-lessons/, find a short list of points which summarizes and touches on all of his lessons
Answer:
Here’s a short “umbrella list” that still covers all 21 lessons (each bullet is doing a lot of work on purpose):
- Start with the user, not the toy. Get unreasonably concrete about real user pain (tickets, observation, “why” drills), and let solutions fall out of that—otherwise you’ll build complexity to justify a preconceived answer.
- Engineering is a team sport: alignment beats being right. The job is getting to “right” together: create shared understanding, reduce misalignment (the real cause of “slow” teams), avoid “winning” debates into silent resistance, use metrics carefully (they get gamed), and design process to reduce uncertainty rather than produce paperwork.
- Ship early, then iterate—clarity over cleverness. Bias to action: drafts and MVPs teach faster than armchair perfection. Write code and docs that are obvious at 2am during an incident, not “impressive.” And treat novelty as debt you repay in ops/hiring/cognitive overhead—spend your “innovation tokens” where you’re uniquely paid to innovate.
- Do less: deletion is a superpower (and often the fastest optimization). Prefer “code you never wrote” (or work you removed) over clever additions. Many performance wins come from removing unnecessary computation, not adding fancy machinery.
- Respect scale and failure: compatibility, migrations, and leaky abstractions are the real product. At scale, even bugs become dependencies; deprecations are migrations with empathy/tooling/time. Abstractions don’t erase complexity—they postpone it until on-call—so keep a working mental model of what’s underneath.
- Make your impact legible and invest in compounding. Code doesn’t advocate for you—people do—so communicate outcomes, not just activity. Use writing/teaching to force clarity and deepen your own understanding; treat “glue work” as deliberate, bounded, and visible. Build psychological safety by saying “I don’t know.” Maintain relationships because your network outlasts any job. And manage your career like compound interest: protect time, practice deliberately, turn scar tissue into reusable playbooks.The writing is excellent.
Very correlated with the quality of the message I'd imagine.
This is a good list. Original, evidence to me that the author is the real deal.
Great post, Years following Addy. I wonder know how he manages his time, in addition to being a leader at Google, and writing such a valuable blog.
Love love love this. So much wisdom I wish I’d had 30 years ago.
Here’s the tl;dr in my opinion, with my own paraphrase:
> Approach [life] with curiosity and generosity, not transactional hustle.
Everything else essentially follows.