Lessons from 14 Years at Google
When I joined Google ~14 years ago, I thought the job was about writing great code. I was partly right. But the longer Iâve stayed, the more Iâve realized that the engineers who thrive arenât necessar...
When I joined Google ~14 years ago, I thought the job was about writing great code. I was partly right. But the longer Iâve stayed, the more Iâve realized that the engineers who thrive arenât necessarily the best programmers - theyâre the ones whoâve figured out how to navigate everything around the code: the people, the politics, the alignment, the ambiguity.
These lessons are what I wish Iâd known earlier. Some would have saved me months of frustration. Others took years to fully understand. None of them are about specific technologies - those change too fast to matter. Theyâre about the patterns that keep showing up, project after project, team after team.
Iâm sharing them because Iâve benefited enormously from engineers who did the same for me. Consider this my attempt to pay it forward.
1. The best engineers are obsessed with solving user problems.
Itâs seductive to fall in love with a technology and go looking for places to apply it. Iâve done it. Everyone has. But the engineers who create the most value work backwards: they become obsessed with understanding user problems deeply, and let solutions emerge from that understanding.
User obsession means spending time in support tickets, talking to users, watching users struggle, asking âwhyâ until you hit bedrock. The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected.
The engineer who starts with a solution tends to build complexity in search of a justification.
2. Being right is cheap. Getting to right together is the real work.
You can win every technical argument and lose the project. Iâve watched brilliant engineers accrue silent resentment by always being the smartest person in the room. The cost shows up later as âmysterious execution issuesâ and âstrange resistance.â
The skill isnât being right. Itâs entering discussions to align on the problem, creating space for others, and remaining skeptical of your own certainty.
Strong opinions, weakly held - not because you lack conviction, but because decisions made under uncertainty shouldnât be welded to identity.
3. Bias towards action. Ship. You can edit a bad page, but you canât edit a blank one.
The quest for perfection is paralyzing. Iâve watched engineers spend weeks debating the ideal architecture for something theyâve never built. The perfect solution rarely emerges from thought alone - it emerges from contact with reality. AI can in many ways help here.
First do it, then do it right, then do it better. Get the ugly prototype in front of users. Write the messy first draft of the design doc. Ship the MVP that embarrasses you slightly. Youâll learn more from one week of real feedback than a month of theoretical debate.
Momentum creates clarity. Analysis paralysis creates nothing.
4. Clarity is seniority. Cleverness is overhead.
The instinct to write clever code is almost universal among engineers. It feels like proof of competence.
But software engineering is what happens when you add time and other programmers. In that environment, clarity isnât a style preference - itâs operational risk reduction.
Your code is a strategy memo to strangers who will maintain it at 2am during an outage. Optimize for their comprehension, not your elegance. The senior engineers I respect most have learned to trade cleverness for clarity, every time.
5. Novelty is a loan you repay in outages, hiring, and cognitive overhead.
Treat your technology choices like an organization with a small âinnovation tokenâ budget. Spend one each time you adopt something materially non-standard. You canât afford many.
The punchline isnât ânever innovate.â Itâs âinnovate only where youâre uniquely paid to innovate.â Everything else should default to boring, because boring has known failure modes.
The âbest tool for the jobâ is often the âleast-worst tool across many jobsâ-because operating a zoo becomes the real tax.
6. Your code doesnât advocate for you. People do.
Early in my career, I believed great work would speak for itself. I was wrong. Code sits silently in a repository. Your manager mentions you in a meeting, or they donât. A peer recommends you for a project, or someone else.
In large organizations, decisions get made in meetings youâre not invited to, using summaries you didnât write, by people who have five minutes and twelve priorities. If no one can articulate your impact when youâre not in the room, your impact is effectively optional.
This isnât strictly about self-promotion. Itâs about making the value chain legible to everyone- including yourself.
7. The best code is the code you never had to write.
We celebrate creation in engineering culture. Nobody gets promoted for deleting code, even though deletion often improves a system more than addition. Every line of code you donât write is a line you never have to debug, maintain, or explain.
Before you build, exhaust the question: âWhat would happen if we just⊠didnât?â Sometimes the answer is ânothing bad,â and thatâs your solution.
The problem isnât that engineers canât write code or use AI to do so. Itâs that weâre so good at writing it that we forget to ask whether we should.
8. At scale, even your bugs have users.
With enough users, every observable behavior becomes a dependency - regardless of what you promised. Someone is scraping your API, automating your quirks, caching your bugs.
This creates a career-level insight: you canât treat compatibility work as âmaintenanceâ and new features as âreal work.â Compatibility is product.
Design your deprecations as migrations with time, tooling, and empathy. Most âAPI designâ is actually âAPI retirement.â
9. Most âslowâ teams are actually misaligned teams.
When a project drags, the instinct is to blame execution: people arenât working hard enough, the technology is wrong, there arenât enough engineers. Usually none of that is the real problem.
In large companies, teams are your unit of concurrency, but coordination costs grow geometrically as teams multiply. Most slowness is actually alignment failure - people building the wrong things, or the right things in incompatible ways.
Senior engineers spend more time clarifying direction, interfaces, and priorities than âwriting code fasterâ because thatâs where the actual bottleneck lives.
10. Focus on what you can control. Ignore what you canât.
In a large company, countless variables are outside your control - organizational changes, management decisions, market shifts, product pivots. Dwelling on these creates anxiety without agency.
The engineers who stay sane and effective zero in on their sphere of influence. You canât control whether a reorg happens. You can control the quality of your work, how you respond, and what you learn. When faced with uncertainty, break problems into pieces and identify the specific actions available to you.
This isnât passive acceptance but it is strategic focus. Energy spent on what you canât change is energy stolen from what you can.
11. Abstractions donât remove complexity. They move it to the day youâre on call.
Every abstraction is a bet that you wonât need to understand whatâs underneath. Sometimes you win that bet. But something always leaks, and when it does, you need to know what youâre standing on.
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.
But keep a working model of its underlying failure modes.
12. Writing forces clarity. The fastest way to learn something better is to try teaching it.
Writing forces clarity. When I explain a concept to others - in a doc, a talk, a code review comment, even just chatting with AI - I discover the gaps in my own understanding. The act of making something legible to someone else makes it more legible to me.
This doesnât mean that youâre going to learn how to be a surgeon by teaching it, but the premise still holds largely true in the software engineering domain.
This isnât just about being generous with knowledge. Itâs a selfish learning hack. If you think you understand something, try to explain it simply. The places where you stumble are the places where your understanding is shallow.
Teaching is debugging your own mental models.
13. The work that makes other work possible is priceless - and invisible.
Glue work - documentation, onboarding, cross-team coordination, process improvement - is vital. But if you do it unconsciously, it can stall your technical trajectory and burn you out. The trap is doing it as âhelpfulnessâ rather than treating it as deliberate, bounded, visible impact.
Timebox it. Rotate it. Turn it into artifacts: docs, templates, automation. And make it legible as impact, not as personality trait.
Priceless and invisible is a dangerous combination for your career.
14. If you win every debate, youâre probably accumulating silent resistance.
Iâve learned to be suspicious of my own certainty. When I âwinâ too easily, something is usually wrong. People stop fighting you not because youâve convinced them, but because theyâve given up trying - and theyâll express that disagreement in execution, not meetings.
Real alignment takes longer. You have to actually understand other perspectives, incorporate feedback, and sometimes change your mind publicly.
The short-term feeling of being right is worth much less than the long-term reality of building things with willing collaborators.
15. When a measure becomes a target, it stops measuring.
Every metric you expose to management will eventually be gamed. Not through malice, but because humans optimize for whatâs measured.
If you track lines of code, youâll get more lines. If you track velocity, youâll get inflated estimates.
The senior move: respond to every metric request with a pair. One for speed. One for quality or risk. Then insist on interpreting trends, not worshiping thresholds. The goal is insight, not surveillance.
16. Admitting what you donât know creates more safety than pretending you do.
Senior engineers who say âI donât knowâ arenât showing weakness - theyâre creating permission. When a leader admits uncertainty, it signals that the room is safe for others to do the same. The alternative is a culture where everyone pretends to understand and problems stay hidden until they explode.
Iâve seen teams where the most senior person never admitted confusion, and Iâve seen the damage. Questions donât get asked. Assumptions donât get challenged. Junior engineers stay silent because they assume everyone else gets it.
Model curiosity, and you get a team that actually learns.
17. Your network outlasts every job youâll ever have.
Early in my career, I focused on the work and neglected networking. In hindsight, this was a mistake. Colleagues who invested in relationships - inside and outside the company - reaped benefits for decades.
They heard about opportunities first, could build bridges faster, got recommended for roles, and co-founded ventures with people theyâd built trust with over years.
Your job isnât forever, but your network is. Approach it with curiosity and generosity, not transactional hustle.
When the time comes to move on, itâs often relationships that open the door.
18. Most performance wins come from removing work, not adding cleverness.
When systems get slow, the instinct is to add: caching layers, parallel processing, smarter algorithms. Sometimes thatâs right. But Iâve seen more performance wins from asking âwhat are we computing that we donât need?â
Deleting unnecessary work is almost always more impactful than doing necessary work faster. The fastest code is code that never runs.
Before you optimize, question whether the work should exist at all.
19. Process exists to reduce uncertainty, not to create paper trails.
The best process makes coordination easier and failures cheaper. The worst process is bureaucratic theater - it exists not to help but to assign blame when things go wrong.
If you canât explain how a process reduces risk or increases clarity, itâs probably just overhead.
And if people are spending more time documenting their work than doing it, something has gone deeply wrong.
20. Eventually, time becomes worth more than money. Act accordingly.
Early in your career, you trade time for money - and thatâs fine. But at some point, the calculus inverts. You start to realize that time is the non-renewable resource.
Iâve watched senior engineers burn out chasing the next promo level, optimizing for a few more percentage points of compensation. Some of them got it. Most of them wondered, afterward, if it was worth what they gave up.
The answer isnât âdonât work hard.â Itâs âknow what youâre trading, and make the trade deliberately.â
21. There are no shortcuts, but there is compounding.
Expertise comes from deliberate practice - pushing slightly beyond your current skill, reflecting, repeating. For years. Thereâs no condensed version.
But hereâs the hopeful part: learning compounds when it creates new options, not just new trivia. Write - not for engagement, but for clarity. Build reusable primitives. Collect scar tissue into playbooks.
The engineer who treats their career as compound interest, not lottery tickets, tends to end up much further ahead.
A final thought
Twenty-one lessons sounds like a lot, but they really come down to a few core ideas: stay curious, stay humble, and remember that the work is always about people - the users youâre building for and the teammates youâre building with.
A career in engineering is long enough to make plenty of mistakes and still come out ahead. The engineers I admire most arenât the ones who got everything right - theyâre the ones who learned from what went wrong, shared what they discovered, and kept showing up.
If youâre early in your journey, know that it gets richer with time. If youâre deep into it, I hope some of these resonate.