Programming is not difficult; the challenge lies in handling “people” and “complexity.” Senior Google engineers share 14 years of insights, from user-centric thinking to team collaboration. These 21 golden rules will help you achieve a more profound career.
（Background recap: Google real-time translation officially opens to all headphone brands: 70+ languages online, US-Mexico-India Android phones first release）
（Additional background: Google officially launches “Gemini 3”! Reaching the top of the world’s smartest AI models, what are the highlights?）

Table of Contents

• 1. Top engineers are obsessed with solving user problems
• 2. “Proving you’re right” is worthless; achieving correct goals together is what matters
• 3. Focus on action. Deploy! You can modify a bad page, but not a blank one
• 4. Seniority shows in clarity; intelligence shows in burden
• 5. “Novelty” is a high-interest loan borrowed from maintenance, recruitment, and cognitive load
• 6. Code won’t speak for you; people will
• 7. The best code is the one you never write
• 8. When scale is large enough, even your bugs have users
• 9. Most “slow” teams are actually “disfocused” teams
• 10. Focus on what you can control, ignore what you can’t
• 11. Abstraction doesn’t eliminate complexity; it just shifts it
• 12. Writing enforces clarity; teaching is the fastest way to learn
• 13. Making other work possible is priceless, yet invisible
• 14. If you win every argument, you might be accumulating silent resistance
• 15. When metrics become goals, they are no longer good metrics
• 16. Admitting “I don’t know” creates more safety than pretending to understand
• 17. Your context lasts longer than any job you’ve done
• 18. Most performance improvements come from “removing work,” not “smart algorithms”
• 19. Processes exist to reduce uncertainty, not to create paperwork
• 20. Ultimately, time is more valuable than money; act accordingly
• 21. There are no shortcuts, only compound interest

• Final thoughts

Addy Osmani, Director of AI at Google Cloud, is an experienced software engineer and thinker. He served as Head of Developer Experience at Chrome for nearly 14 years, involved in projects like DevTools, Lighthouse, and Core Web Vitals. Now, he coordinates work among Google DeepMind, engineering, product, and developer relations teams.

He published an in-depth career reflection on his personal blog over three days. Combining his years of experience at Google with professional insights, he summarized 21 valuable suggestions on communication, technical choices, and career planning, compiled and translated below:

When I joined Google about 14 years ago, I thought this job was about writing perfect code. I was only partly right. The longer I stayed, the more I realized that high-performing engineers are not necessarily those who write the best code, but those who have learned how to master everything outside of code: including interpersonal relationships, workplace politics, consensus alignment, and dealing with uncertainty.

These lessons are what I wish I had understood earlier. Some saved me months of frustration; others took years to truly grasp. None are about specific technologies: tech changes too fast to matter. They are about patterns that recur across different projects and teams.

I share these because I have benefited greatly from engineers willing to mentor juniors. This is my way of giving back.

1. Top engineers are obsessed with solving user problems

Loving a technology and seeking application scenarios everywhere is very tempting. I’ve done it, everyone has. But the engineers who create the most value are those who do “reverse work”: they obsess over deeply understanding user problems, letting solutions naturally emerge from this understanding.

User obsession means spending time reviewing customer support tickets, talking to users, observing their operational difficulties, and constantly asking “why” until reaching the core. Engineers who truly understand the problem often find that elegant solutions are simpler than expected. Engineers who start from solutions tend to add unnecessary complexity to rationalize their choices.

2. “Proving you’re right” is worthless; achieving correct goals together is what matters

You can win every technical debate but lose the entire project. I’ve seen smart engineers accumulate silent resentment because they always want to be the smartest in the room. The cost later manifests as “mysterious execution issues” or “unexplained resistance.”

Skills are not about being “correct,” but about engaging in discussions to align problems, creating space for others, and doubting your own certainty. Strong opinions, open minds — this is not because you lack conviction, but because decisions made under uncertainty should not be tied to your ego.

3. Focus on action. Deploy! You can fix a bad page, but not a blank one

Perfectionism leads to paralysis. I’ve seen engineers spend weeks debating ideal architectures for things they’ve never built. Perfect solutions rarely come from pure thinking—they come from real-world collision. AI can help in many ways.

Do first, do right, then do better. Push out a rough prototype to users. Write a messy draft of the design document. Release that MVP that makes you slightly uncomfortable. Learning from a week of real feedback beats a month of theoretical debate. Momentum brings clarity; analysis paralysis yields nothing.

4. Seniority shows in clarity; intelligence shows in burden

The instinct to write “smart” code is almost universal among engineers—it feels like a proof of ability. But software engineering is a “reaction” of “time” plus “other engineers.” In this environment, clarity is not a style preference but a way to reduce operational risk.

Your code is a strategic memo for strangers who might fix issues at 2 a.m. Improve their understanding, not your elegance. The most respected senior engineers always choose “clarity” over “smartness.”

5. “Novelty” is a high-interest loan borrowed from maintenance, recruitment, and cognitive load

Treat your technical choices as a “startup” with limited “innovation tokens.” Every time you adopt a non-standard technology, you spend one. You can’t afford too many. The point is not “never innovate,” but “only innovate where you get a unique payoff.”

Everything else should be considered “boring,” because boredom means its failure modes are known. “Tools best suited for the job” are often “tools that perform least badly across multiple tasks”—managing a zoo of technologies becomes a real burden.

6. Code won’t speak for you; people will

Early in my career, I thought excellent performance would speak for itself. I was wrong. Code quietly stays in repositories. Whether your manager mentions you in meetings or colleagues recommend you for projects is what matters.

In large organizations, decisions are made in uninvited meetings, by people with only five minutes to handle a dozen priorities, based on summaries you never wrote. If no one can clearly articulate your impact when you’re absent, your influence is negligible. It’s not just self-promotion; it’s about making the value chain visible to everyone (including yourself).

7. The best code is the one you never write

Engineering culture celebrates creation. No one gets promoted for deleting code, even though deletion often optimizes systems more than adding. Every line of code you never write is a line you never need to debug, maintain, or explain.

Before building, ask yourself thoroughly: “What if we just don’t do this?” Sometimes the answer is “nothing bad happens,” and that’s your solution. The problem isn’t that engineers can’t write code or use AI to generate it, but that we’re so good at writing code that we forget to ask “should we write it?”

8. When scale is large enough, even your bugs have users

When users are numerous enough, any observable behavior becomes a dependency—regardless of what you originally promised (Hale’s Law). Someone is crawling your API, automating your quirky features, caching your bugs.

This yields a professional insight: you cannot treat compatibility work as “maintenance” and new features as “real work.” Compatibility is the product itself. When designing deprecation plans, treat them as migration processes with time, tools, and empathy. Most “API design” is actually “API retirement.”

9. Most “slow” teams are actually “disfocused” teams

When projects stall, the instinct is to blame execution: not enough people, wrong tech stack. Usually, these are not the core issues. In big companies, teams are your concurrency units, but coordination costs grow geometrically with team size. Most slowness is actually misalignment—people building the wrong things or building correct things in incompatible ways. Senior engineers spend more time clarifying direction, interfaces, and priorities than “writing faster code,” because that’s the real bottleneck.

10. Focus on what you can control; ignore what you can’t

In large companies, countless variables are beyond your control—organizational restructuring, management decisions, market shifts, product pivots. Worrying about these causes anxiety and is futile. A rational and effective engineer focuses on their circle of influence.

You can’t control reorganizations, but you can control work quality, your reactions, and what you learn. When facing uncertainty, break down problems and identify specific actions you can take. This is not passive acceptance but strategic focus. Spending energy on things you cannot change steals from what you can.

11. Abstraction doesn’t eliminate complexity; it just shifts it

Every abstraction is a gamble—betting you won’t need to understand the underlying principles. Sometimes you win, but abstractions always leak. When they fail, you need to know what’s happening underneath. Senior engineers keep learning “bottom-layer” knowledge even as their tech stacks grow higher. It’s not nostalgia but respect for moments when abstractions break down. Use your tools, but understand their failure modes through mental models of their underlying layers.

12. Writing enforces clarity; teaching is the fastest way to learn

Writing forces you to think. When I explain a concept—whether in documentation, presentations, code reviews, or chatting with AI—I discover gaps in my understanding.

Making content clear to others also clarifies it for me. It’s not just generous knowledge sharing; it’s a selfish learning technique. If you think you understand something, try explaining it simply. The points where you get stuck reveal shallow understanding. Teaching is debugging your mental models.

13. Making other work possible is priceless, yet invisible

“Glue work”—documentation, onboarding, cross-team coordination, process improvements—is crucial. But if you do it unconsciously, it hampers your technical growth and exhausts you. The trap is treating it as “helping,” rather than as conscious, bounded, visible contribution. Limit time, rotate roles, turn it into output (documents, templates, automation).

View it as influence, not personality trait.

14. If you win every argument, you might be accumulating silent resistance

I’ve learned to doubt my certainty. When I “win” too easily, something’s off. People stop arguing not because they’re convinced, but because they give up trying—they express disagreement during execution, not in meetings. True alignment takes longer.

You must genuinely understand others’ perspectives, incorporate feedback, and sometimes openly change your mind. The short-term thrill of winning debates is far less valuable than long-term collaboration with genuinely convinced partners.

15. When metrics become goals, they are no longer good metrics

Every metric you show management will eventually be “gamed.” Not out of malice, but because humans optimize for what’s measured (Goodhart’s Law). If you track lines of code, you get more lines. If you track speed, you get inflated estimates.

Senior practice: for each metric request, provide a pair—one for velocity, one for quality or risk. Insist on interpreting trends, not worshiping thresholds. The goal is insight, not surveillance.

16. Admitting “I don’t know” creates more safety than pretending to understand

A senior engineer who says “I don’t know” is not showing weakness but creating “permission.” When leaders admit uncertainty, they send a signal: this room is safe for others. I’ve seen senior teams that never admit confusion—this causes harm: no one asks questions, assumptions go unchallenged, junior engineers stay silent, thinking only they don’t understand. Model curiosity, and you’ll get a team that truly learns.

17. Your context lasts longer than any job you’ve done

Early in my career, I focused on work and neglected relationships. Looking back, that was a mistake. Investing in relationships (colleagues inside and outside the company) has benefited me for decades. They hear about opportunities first, can build bridges faster, get recommendations, and co-found ventures with trusted contacts. Jobs are temporary, but relationships are forever. Build them with curiosity and generosity, not transactional mindset.

18. Most performance gains come from “removing work,” not “smart algorithms”

When systems slow down, the instinct is to add caches, parallelism, smarter algorithms. Sometimes that’s right, but I’ve seen more performance improvements from asking: “What unnecessary work are we doing?” Removing unnecessary work almost always beats doing faster necessary work. The fastest code is code that never runs.

19. Processes exist to reduce uncertainty, not to create paperwork

The best processes make coordination easier and failure costs lower. The worst are “bureaucratic drama”—they exist not to help but to shift blame when things go wrong. If you can’t explain how a process reduces risk or increases clarity, it might just be a burden. If people spend more time documenting than doing, it’s a big problem.

20. Ultimately, time is more valuable than money; act accordingly

Early in your career, you trade time for money—no problem. But at some point, the calculation reverses. You realize time is non-renewable. I’ve seen senior engineers exhausted chasing the next rank or optimizing a few percentage points of salary. Some succeed, but most later question if it’s worth the cost. The answer is not “don’t work hard,” but know what you’re trading and do it consciously.

21. There are no shortcuts, only compound interest

Expertise comes from deliberate practice—slightly beyond your current skills, reflecting, repeating, and persisting for years. No shortcuts. But the hope is: when learning creates new options rather than just scattered knowledge, it compounds. Writing (for clarity), building reusable components, collecting painful lessons into manuals. Engineers who see their careers as “compound interest” rather than “lottery” tend to go much further.

Final thoughts

These 21 points may seem many, but the core ideas are only a few: stay curious, stay humble, and remember that work is always about people—including your users and teammates.

Engineering careers are long enough to allow many mistakes and still succeed. The most admirable engineers are not those who never err, but those who learn from mistakes, share discoveries, and persist.

If you’re just starting, know that it will become more exciting over time. If you’ve been in it for years, I hope some of these resonate with you.