21 Lessons I Learned in 14 Years at Google

I joined Google about 14 years ago, and back then I thought my job would be writing good code. That was partly true. But the longer I worked there, the more I realized that the most successful engineers aren't necessarily the best programmers. They're usually the people who learned to navigate everything that surrounds code — people, internal politics, and uncertainty.

Over all that time, I picked up many lessons that definitely would have been useful from the start. Some would have saved me months of frustration. Others took years to understand. None of them are about specific technologies, which change too often to matter much. They're all about patterns that keep showing up again and again — in every project and every team.

I decided to share them because I learned them thanks to other engineers who helped me along the way. So in a sense, I'm passing the baton.

1. The Best Engineers Always Strive to Solve User Problems

It's very easy to fall in love with a technology and start looking for places to apply it. That happened to me, and to many others. But the engineers who create the most value do the opposite — they deeply immerse themselves in user problems and generate their solutions from that state.

This immersion manifests as dedicating time to processing tickets, talking to users, examining their problems, and racking your brain until you get to the root cause. When a developer truly digs into the problem, they often discover that the elegant solution is simpler than expected.

Those who jump straight to a hasty solution often overcomplicate everything in their effort to justify it.

2. Being Right Isn't the Point — Finding Consensus Is

You can win every technical argument and still lose the project. I've seen brilliant engineers silently accumulate resentment every time, believing themselves to be the smartest person in the discussion. Later this turns into "mysterious implementation difficulties" and "strange resistance."

But in these cases, mastery isn't about always being right. It lies in the ability to participate constructively in a discussion to align on a shared vision, in showing tolerance for others' opinions, and in being more skeptical of your own infallibility.

It's important to express your confident opinion while being ready to change it — not because you lack assertiveness, but because decisions made under uncertainty shouldn't be tied to a single individual.

3. Be Decisive, Don't Delay the Release — You Can Fix a Bad Page, but You Can't Fix a Blank One

The quest for perfection is incredibly addictive. I've watched developers argue for weeks about the ideal architecture for something they've never built. The perfect solution rarely emerges from thinking alone — it usually comes from contact with reality. And AI can actually help here.

First just build something, then polish it, then improve it. Don't be afraid to ship a rough prototype to users. Let the first version of a design document be messy. Deploy an MVP you're a little embarrassed by. A week of real feedback will teach you more than months of theoretical debates.

Momentum brings clarity. Analysis paralysis creates nothing.

4. Strive for Clarity — Cleverness Has Hidden Costs

The instinct to write clever code is common among almost all developers. As if it should prove their competence.

But the software development process includes an element of time and the involvement of many programmers. In that context, clarity stops being a personal preference and becomes a means of reducing operational risk.

Your code is a strategic memo for strangers who will be debugging it at 2 AM during an outage. So when writing it, focus on clarity rather than apparent elegance. Most of the senior engineers I respect learned to trade cleverness for clarity.

5. Innovation Is a Loan You Repay Through Outages, Hiring, and Cognitive Load

Think of your technical choices as an organization with a small budget of "innovation tokens." Spend one each time you introduce something non-standard. You can't afford many of them.

The key point here isn't to reject innovation but to "adopt it only when it provides a unique return." In all other cases, follow the boring, well-trodden paths, because their dangers are already known.

The best tool for any individual task is often "the least problematic one that works for many tasks," because managing a whole zoo of exotic technologies is far more difficult.

6. It's Not Code That Gets You Promoted — It's People

Early in my career, I believed that excellent work should speak for itself. That was a mistake. Code sits quietly in the repository, but your manager either mentions you in a meeting or doesn't, and so does a colleague or acquaintance who might suggest your name for a promising project.

In large organizations, decisions are made in meetings you aren't invited to, based on reports you didn't write, by busy people who have 5 minutes and 12 priorities. If nobody highlights your role when you're not in the room, your role effectively becomes mediocre.

And this isn't necessarily about personal growth — it's about making the value chain in the organization transparent to everyone, including yourself.

7. The Best Code Is the Code You Didn't Have to Write

In development culture, we celebrate creation. Nobody gets promoted for deleting code, even though it often benefits the system more than adding it. Every line of code you don't write is a line you won't have to debug, maintain, or explain.

Before building anything, ask yourself: "What would happen if we simply... didn't do this?" Sometimes the answer is "nothing bad," and that becomes your solution.

And the problem isn't that engineers can't write code or use AI for it. It's that we're so good at it that we sometimes forget to think about whether certain things are even needed.

8. At Scale, Even Your Bugs Have Users

Whatever you originally promised your users, given enough of them, any observable behavior becomes a dependency. Someone is scraping your API, embedding non-standard software features into their workflows, and caching bugs.

This leads to an important career insight: you can't treat backward compatibility as "maintenance" and adding new features as "real work." Compatibility is also a product.

Design the deprecation of features as a migration with appropriate timelines, tooling, and consideration for user interests. In practice, a significant part of "API design" actually consists of shutting down deprecated API functions.

9. Most Teams' "Slowness" Is Actually Misalignment

When a project drifts, we instinctively blame execution — people aren't working hard enough, the technology is wrong, there aren't enough developers. But usually none of this is the real problem.

In large companies, teams act as units of internal "currency," but as their number grows, coordination costs increase exponentially. Most slowness comes down to alignment problems — people are building the wrong thing or ignoring necessary compatibility.

Senior engineers spend more time clarifying shared direction, interfaces, and priorities than on "speeding up coding," because those aspects turn out to be the actual bottleneck.

10. Focus on What You Can Control, Ignore What You Can't

In large companies, a huge number of variables are outside your control. Organizational changes, leadership decisions, market fluctuations, product pivots. Paying too much attention to all of this only breeds unnecessary anxiety about things you can't influence.

Engineers who maintain a healthy perspective focus their attention on their sphere of control. You can't influence whether a reorg will happen, but you can change your reaction and the quality of your work, shaping the experience you gain. When facing uncertainty, break tasks into parts and identify which specific actions are available to you.

This is not a sign of passive acceptance but of strategic focus. The energy spent on things you can't change can be redirected to things within your power.

11. Abstractions Don't Remove Complexity — They Just Shift It Until You're the One on Call

When creating any abstraction, you're betting that you won't need to understand what's happening underneath it. Sometimes that bet pays off. But sooner or later, something leaks through, and when it does, you need to know exactly what you're dealing with.

Senior engineers continue to learn "low-level" details even when it requires increasing effort. It's not about nostalgia — it's the awareness that one day the abstraction will collapse, and you'll be left face-to-face with the system at 3 AM. Use your stack. But keep a working mental model of potential internal failure modes.

12. The Fastest Way to Learn Something Is to Start Teaching It

Writing information down helps you understand it better. When I explain a concept to others — whether in documentation, conversation, code review, or even a chat with AI — I find gaps in my own understanding. The mere act of trying to clarify something for someone else makes it clearer to me.

This doesn't mean that to master surgery you need to start teaching it to others. But in software development, this idea works most of the time.

And it's not about generously sharing knowledge. It's actually just a selfish learning hack. If you think you understand something, try explaining it in plain language. The moments where you stumble will point to the gaps in your understanding.

Teaching is a form of debugging your own mental models.

13. Work That Makes Other Work Possible Is Invaluable and Invisible

Connective work — documentation, onboarding, team coordination, process optimization — is vital. But if done unconsciously, it can stall your technical development trajectory and lead to burnout. The trap is that we approach it as mutual aid rather than a clearly defined task with visible outcomes.

Set time limits for such activities. Transform them into artifacts: documents, templates, and automated mechanisms. Make sure they lead to obvious results rather than merely reflecting personal quality.

Being invaluable and invisible is a dangerous combination for your career.

14. If You're Winning Every Argument, You're Probably Building Up Silent Disagreement

I learned to accept the possibility of being wrong in my own beliefs. When I "win" an argument too easily, it usually means something is off. People stop arguing with you not because you've convinced them, but because they're tired of trying — and they'll express that disagreement through their work, not in meetings.

Achieving real agreement on an issue takes more time. You need to delve into other viewpoints and understand them, gather feedback, and sometimes openly change your mind.

The short-term feeling of being right is far less valuable than the long-term experience of working on a project with people who share a common vision.

15. When a Metric Becomes a Target, It Ceases to Be a Metric

Any metric you present to leadership will eventually become an object of manipulation. It's not about ill intent — people naturally tend to optimize for whatever is being measured.

If you track work efficiency by lines of code, you'll get more and more of them. If efficiency is tracked by velocity, teams will inflate their estimates.

How do experienced engineers handle this? They pair every requested metric with a counterbalancing one. One for speed — another for quality or risk assessment. They also focus on interpreting overall trends rather than intermediate results. The goal is to get a clear picture, not to set up surveillance.

16. Admitting You Don't Know Something Is Safer Than Pretending You Do

When a senior engineer says "I don't know," it's not a show of weakness — it defuses the situation. When a leader expresses uncertainty, it signals that others in the meeting can do the same. In organizations with the opposite culture, everyone pretends to understand everything. As a result, real problems go unnoticed until critical moments arrive.

I've seen teams where the lead never admitted any doubt, and I've also seen the unfortunate consequences of that behavior. In such environments, the right questions don't get asked, stated assumptions go unchallenged, and juniors stay silent because they believe everyone else understands.

Show genuine interest in discussion, and you'll get a team that truly learns.

17. Your Professional Network Will Outlast Any Job

Early in my career, I focused only on work, neglecting professional relationships. Looking back, I realize that was a mistake. My colleagues who invested in connecting with other people — both inside the company and outside its doors — reaped the rewards for decades.

They learned about emerging opportunities earlier, built bridges faster, got referrals to promising positions, and founded companies with people they had built trust-based relationships with.

Your current job will end sooner or later, but your professional connections will last forever. Approach building them with curiosity and sincerity, not out of self-interest.

When the time comes to move on, it's often your connections with people that open the most promising doors.

18. The Biggest Performance Gains Usually Come from Eliminating Unnecessary Work, Not Adding More

When systems slow down, we instinctively want to add things: caching layers, parallel processing, smarter algorithms. Sometimes that's the right call. But I've personally seen performance gains more often after answering the question: "Which of our current computations do we not need?"

Removing unnecessary work almost always delivers more benefit than speeding it up. The fastest code is the code that never runs.

Before optimizing something, ask whether that component is even necessary.

19. Process Exists to Reduce Uncertainty, Not to Create a Paper Trail

Good processes simplify coordination and reduce the impact of failures. Bad ones just create bureaucratic theater that doesn't help identify who's responsible when errors occur.

If you can't explain how a given process reduces risk or increases clarity, it's probably just unnecessary overhead.

And if people are spending more time documenting their work than actually doing it, something is clearly wrong.

20. In the End, Time Is More Valuable Than Money — Act Accordingly

Early in your career, you prioritize money over time — and that's normal. But at a certain point, the terms of that equation switch. You begin to understand that time is not a renewable resource.

I've watched senior engineers burn out chasing the next promotion, diligently optimizing programs for a modest salary bump. Some of them succeeded. But most later wondered whether it was worth it.

The secret isn't to "work hard" — it's to "consciously choose which values to prioritize."

21. There Are No Shortcuts, but There Is the Power of Compounding

Experience comes from deliberate practice — pushing slightly beyond your current skill level, reflecting on it, and then doing it again. Year after year. There's no concentrated form of it.

But there's one pleasant feature of learning: experience grows when we create new solutions, not when we simply generate new information. Write not out of formal obligation but with an emphasis on clarity. Build primitives that can be reused elsewhere. Turn all your painful experiences into useful guides.

An engineer who views their career as an investment in the future rather than a lottery ticket achieves far more.

In Closing

Twenty-one lessons may seem like a lot, but at their core they boil down to a few key ideas — stay curious and keep things simple, and remember that work is always about people — the users you're building the product for and the colleagues you work alongside.

A career in software engineering is long enough to make plenty of mistakes and still come out ahead. Personally, the developers I admire most aren't the ones who always do everything right, but the ones who learn from their mistakes, share their knowledge, and persist.

If you're just starting out, know that there's a lot of interesting stuff ahead. If you're already deep in the game, I hope some of my advice resonated with you.