Addy Osmani, Google Cloud AI director and former Chrome developer experience lead for nearly 14 years, published a deep career reflection on his personal blog on July 3. Drawing from his tenure at Google, he distilled 21 golden rules on communication, technology choices, and career planning. Here are the highlights.
Top engineers obsess over user problems
Falling in love with a technology and hunting for applications is tempting, Osmani writes. But the engineers who create the most value work backwards: they immerse themselves in customer support tickets, talk to users, watch them struggle, and keep asking “why” until hitting the core. Engineers who start from the solution often add unnecessary complexity to justify their choice.
Bias for action: ship ugly, improve later
Perfectionism leads to paralysis. Osmani’s advice: “Make it work, make it right, make it better.” Push a rough prototype to users, release an embarrassing MVP. One week of real feedback teaches more than a month of theoretical debate. “Momentum brings clarity; analysis paralysis delivers nothing.”
Clarity over cleverness
The instinct to write clever code is universal, but software engineering is a chemical reaction of time and other programmers. Clarity is not a style preference; it’s risk reduction. Code is a strategic memo to a stranger debugging at 2 a.m. Optimize for their comprehension, not your elegance. Senior engineers consistently trade cleverness for clarity.
Novelty is a high-interest loan
Treat technology choices like a limited budget of “innovation tokens.” Every time you adopt a non-standard technology, you spend one token. Innovate only where you get unique returns, Osmani says. Everything else should default to “boring” because boring means its failure modes are known. The best tool for the job is often the least bad across many jobs—running a tech zoo becomes a real burden.
Code won’t speak for you
Early in his career, Osmani believed great work spoke for itself. He was wrong. Code sits silently in repositories. Decisions happen in meetings you’re not invited to, based on summaries you didn’t write. If no one can articulate your impact when you’re not in the room, your impact is optional. Make your value chain visible to everyone, yourself included.
The best code is the line you never wrote
Engineering culture celebrates creation; no one gets promoted for deleting code. Yet every line not written is one you never have to debug, maintain, or explain. Before building, ask: “What happens if we don’t do this?” Sometimes the answer is “nothing bad”—and that’s your solution. The problem isn’t that engineers can’t write code; it’s that they’re too good at writing it and forget to ask whether they should.
Saying “I don’t know” creates safety
Senior engineers who admit uncertainty aren’t showing weakness; they’re granting permission. When leaders acknowledge uncertainty, it signals that the room is safe for others. Teams where seniors never admit confusion suffer: questions go unasked, assumptions unchallenged, junior engineers stay silent thinking they’re the only ones who don’t understand. Model curiosity, and you’ll get a team that actually learns.
Osmani concludes that the core ideas are few: stay curious, stay humble, and remember that work is always about people—the users you build for and the teammates you build with. A long engineering career allows plenty of mistakes; the best engineers aren’t those who never fail, but those who learn, share, and persist.