Skip to content
Search

Google

lastmod 2026-03-04created 2014-01-1125 edits

Detailed list of Google Products

Google is an American multinational company whose main business areas are web search, cloud computing, and advertising. It was founded in 1998 by Larry Page and Sergey Brin under the name ~BackRub. Google controls two-thirds of all internet searches in the United States and 70% worldwide. In 2008, Google announced that its web page index had passed 1 trillion pages, and it maintains an index more than three times larger than any other search engine. As of early 2009, billions of Google search result pages were visited and tens of billions of Google ads were served every day.

Categories

ETC

  • Genkit - Google's open-source full-stack AI framework
  • Longfellow ZK - Google open-sources its "zero-knowledge proof (ZKP)" technology

Site shortcuts

21 Lessons from 14 Years at Google

  • 21 Lessons from 14 Years at Google | GeekNews
  • Great engineers are not the best programmers but the people who have learned to navigate the people, politics, coordination, and ambiguity around the code
  • Focuses on patterns that recur across projects and teams rather than on technology, covering solving user problems, team collaboration, code quality, career management, and more
  • Shows that clarity is the core quality of a senior engineer and cleverness is just overhead, along with the paradoxical insight that the best code is code you never wrote
  • Exposes the pitfalls of running organizations: in large organizations, misalignment is the main cause of slowdowns, and metrics get distorted once they become targets
  • In the long run, time becomes a more valuable resource than money, and because your network outlasts any single job, deliberate career design is needed

The best engineers are obsessed with solving user problems

  • It is tempting to fall for a technology first and then look for somewhere to apply it, but the engineers who create the most value work backward - they deeply understand the user problem and derive the solution from there
  • User obsession means spending time on support tickets, talking to users, watching users struggle, and asking "why" until you reach the root
  • Engineers who truly understand the problem often find that the elegant solution is simpler than expected
  • Engineers who start from the solution tend to build up complexity to find a justification

Being right is easy; getting to right together is the real job

  • You can win every technical argument and still lose the project; has watched brilliant engineers who were always the smartest person in the room build up quiet resentment
  • The cost shows up later as "mysterious execution problems" and "strange resistance"
  • The key skill is not being right but joining discussions to align on the problem, creating space for others, and staying skeptical of your own certainty
  • Strong opinions, weakly held - not from a lack of conviction, but because decisions made under uncertainty should not be tied to your identity

Ship with a bias toward action. You can edit a bad page, but you can't edit a blank one

  • Chasing perfection leads to paralysis; has watched engineers spend weeks debating the ideal architecture for something they had never built
  • The perfect solution does not come from thinking alone but emerges from contact with reality, and AI can help in several ways
  • Go in this order: do it, do it right, do it better - put an ugly prototype in front of users, write a messy first draft of the design doc, ship a slightly embarrassing MVP
  • You learn more from a week of real feedback than from a month of theoretical debate; momentum creates clarity, and analysis paralysis creates nothing

Clarity is the mark of seniority; cleverness is overhead

  • The instinct to write clever code is nearly universal among engineers and feels like proof of competence
  • Software engineering is what happens when you add time and other programmers, and in that setting clarity means reducing operational risk, not a style preference
  • Code is a strategy memo for the strangers who will maintain it at 2 a.m. during an outage, so optimize for their understanding, not for elegance
  • The most respected senior engineers learn to trade cleverness for clarity every time

Novelty is a debt you repay in outages, hiring, and cognitive overhead

  • Treat technology choices like an organization with a small budget of "innovation tokens," spending one each time you adopt something substantially nonstandard - you can't afford many
  • The point is not "never innovate" but "innovate only where you are uniquely rewarded for innovating"; everywhere else, boring should be the default
  • Because boring has known failure modes
  • "The best tool for the job" often means "the least-worst tool across many jobs" - because running a zoo becomes a real tax

Code doesn't advocate for you; people do

  • Early in his career he believed great work would speak for itself, but that was a mistake; code just sits quietly in the repository
  • Your manager mentions you in a meeting or doesn't; a peer recommends you for a project or recommends someone else
  • In large organizations, decisions are made in meetings you weren't invited to, based on summaries you didn't write, by people with five minutes and twelve priorities
  • If no one can articulate your impact in a room you're not in, that impact is effectively optional; this is not self-promotion but making the value chain legible to everyone, yourself included

The best code is the code you never had to write

  • Engineering culture celebrates creation, but 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
  • Exhaust the question before building: "What happens if we just... don't?" - if the answer is sometimes "nothing bad," that is the solution
  • The problem is not that engineers can't write code or can't write it with AI, but that they write it so well they forget to ask whether they should

At scale, even bugs have users

  • With enough users, every observable behavior becomes a dependency, regardless of what you promised - someone scrapes your API, automates your quirks, and caches your bugs
  • This produces a career-level insight: you can't treat compatibility work as "maintenance" and new features as "real work"; compatibility is the product
  • Design deprecations as migrations, with time, tools, and empathy
  • Most "API design" actually means "API retirement"

Most "slow" teams are actually misaligned teams

  • When a project slips, the instinct is to blame execution - people aren't working hard enough, the technology is wrong, there aren't enough engineers - but that is usually not the real problem
  • In large companies, teams are the unit of concurrency, but coordination costs grow exponentially as teams multiply
  • Most slowness is really alignment failure - building the wrong thing, or building the right thing in incompatible ways
  • Senior engineers spend more time clarifying direction, interfaces, and priorities than "writing code faster" - because that is where the real bottleneck is

Focus on what you can control; ignore what you can't

  • In big companies, countless variables are out of your control - org changes, management decisions, market shifts, product pivots - and dwelling on them creates anxiety without agency
  • Engineers who stay sane and effective focus on their sphere of influence - you can't control whether a reorg happens, but you can control the quality of your work, how you respond, and what you learn
  • When facing uncertainty, break the problem into pieces and identify the concrete actions available to you
  • This is not passive acceptance but strategic focus; energy spent on what you can't change is energy stolen from what you can

Abstractions don't remove complexity; they move it to when you're on call

  • Every abstraction is a bet that you won't need to understand what's underneath, and 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 as the stack grows taller - not out of nostalgia, but out of respect for the moment when the abstraction fails and you're alone with the system at 3 a.m.
  • Use the stack, but keep a working model of its underlying failure modes

Writing forces clarity. The fastest way to learn something better is to try teaching it

  • Writing forces clarity; when you explain a concept to someone else - in a doc, a talk, a code review comment, even a chat with AI - you discover the gaps in your own understanding
  • The act of making something legible to others makes it more legible to yourself
  • This doesn't mean you learn to be a surgeon by teaching surgery, but the premise mostly holds in software engineering
  • This is not just generosity in sharing knowledge but also a selfish learning hack - if you think you understand something, try explaining it simply; where you get stuck is where your understanding is shallow
  • Teaching is debugging your own mental model

Work that enables other work is invaluable but invisible

  • Glue work - documentation, onboarding, cross-team coordination, process improvement - is essential, but done unconsciously it can stall your technical trajectory and lead to burnout
  • The trap is doing it as "being helpful" instead of treating it as deliberate, bounded, visible impact
  • Time-box it, rotate it, and turn it into artifacts: docs, templates, automation - and make it legible as impact, not as a personality trait
  • Invaluable but invisible is a dangerous combination for a career

If you win every argument, you're probably accumulating silent resistance

  • Learned to doubt his own certainty; when he "wins" too easily, something is usually wrong
  • People stop fighting you not because you convinced them but because they gave up, and they express that disagreement in execution, not in 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 far less than the long-term reality of building things with willing collaborators

When a measure becomes a target, it stops measuring

  • Every metric you expose to management eventually gets gamed, not out of malice but because humans optimize for what is measured
  • Track lines of code and you get more lines; track velocity and you get inflated estimates
  • The senior move: answer every metric request with a pair - one for speed, one for quality or risk - then insist on interpreting trends rather than worshiping thresholds
  • The goal is insight, not surveillance

Admitting what you don't know creates more safety than pretending you do

  • A senior engineer who says "I don't know" is not showing weakness but creating permission
  • When leaders admit uncertainty, it signals that others can do the same; the alternative is a culture where everyone pretends to understand and problems stay hidden until they blow up
  • Has seen teams where the most senior person never admitted confusion, and the damage that followed - questions don't get asked, assumptions go unchallenged, and junior engineers stay silent because they assume everyone else understands
  • Model curiosity, and you get a team that actually learns

Your network outlasts every job you'll ever have

  • Early in his career he focused on the work and neglected networking; looking back, that was a mistake
  • Colleagues who invested in relationships - inside and outside the company - reaped the benefits for decades
  • They heard about opportunities first, could build bridges faster, got recommended for roles, and co-founded ventures with people they had built trust with over years
  • Jobs don't last forever, but your network outlasts each one - approach it with curiosity and generosity, not transactional hustle
  • When it's time to leave, it's often relationships that open the door

Most performance wins come from removing work, not adding cleverness

  • When a system gets slow, the instinct is to add - caching layers, parallel processing, smarter algorithms - and sometimes that's right, but he has seen bigger performance gains from asking "what don't we need to compute?"
  • Deleting unnecessary work is almost always more impactful than making necessary work faster; the fastest code is code that never runs
  • Before optimizing, question whether the work needs to exist at all

Process exists to reduce uncertainty, not to create paper trails

  • The best processes make coordination easier and failure cheaper; the worst are bureaucratic theater - they exist 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
  • If people spend more time documenting their work than doing it, something is seriously wrong

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 math flips - you start to realize time is a non-renewable resource
  • Has watched senior engineers burn out chasing the next promotion level and optimizing a few more percentage points of compensation
  • Some got it, but most later wondered whether what they gave up was worth it
  • The answer is not "don't work hard" but "know what you're trading, and trade deliberately"

There are no shortcuts, but there is compounding

  • Expertise comes from deliberate practice - pushing slightly past your current skill, reflecting, repeating - for years - there is no compressed version
  • The hopeful part: learning compounds when it creates new options, not just new trivia
  • Write - for clarity, not engagement - build reusable primitives, and collect scar tissue into playbooks
  • Engineers who treat their career as compound interest tend to get far ahead of those who treat it as a lottery ticket

Final thoughts

  • 21 lessons sounds like a lot, but they really come down to a few core ideas: stay curious, stay humble, and the work is always about people - the users you build for and the teammates you build with
  • An engineering career is long enough to make plenty of mistakes and still come out ahead; the engineers he admires most are not the ones who got everything right but the ones who learned from what went wrong, shared what they found, and kept showing up
  • If you're early in the journey, know that it gets richer over time; if you're deep into it, he hopes some of this resonates

14 More Lessons from 14 Years at Google

  1. The best engineers pick the right problems
    • You can't put maximum energy into everything.
  2. If you don't know what to ask for, you're not ready for the meeting
    • Permission, a decision, unblock, inform - if you can't pick one of these, the meeting will probably be a waste of time.
  3. "I should do it" is not a plan. "I'll do it on Tuesday" is a plan.
    • Setting a concrete date creates momentum.
  4. Slow code is just a symptom; slow decision-making is the real cause.
    • If deciding something takes weeks rather than hours, look into why.
  5. Treat reliability as a product feature
    • Just as you wouldn't ship a feature without reviewing the product, you shouldn't deploy a system without discussing reliability.
  6. If the interfaces between teams are bad, you can't communicate well
    • Vague boundaries and unclear contracts lead to more meetings and Slack channels. It must be clear who owns what and how teams depend on each other.
  7. The best escalation comes with a proposal.
    • Both the person who raises a problem and the person who solves it have identified the issue, but only one of them earns trust and autonomy.
  8. Build systems that don't need heroes
    • If one person keeps saving the company or the team, that is not glory but a sign of decline.
  9. Treat observability as part of the feature
    • Consider "confirmed that the code works well" to be the end of the job.
  10. Small PRs are a kindness. Especially if AI wrote them.
    • Small PRs let you think incrementally, so knowledge can build up bit by bit.
  11. Adding a new team adds not only a node but edges too
    • Unless you deliberately reduce the connections, adding a new team leaves output the same.
  12. A migration is never just a migration
    • Migrations that actually finish have three things in common: a sponsor who stays engaged, a team that genuinely drives the migration, and a clear end date that everyone trusts. If all three are not in place, the migration stays "almost done" forever, and you own two systems forever.
  13. AI makes drafts easy, and taste is becoming rare.
    • The engineers who pick out the very best will be the best of this era.
  14. Trust is a latency optimization
    • Every time you keep a promise, honestly admit a mistake, or make other people's lives easier, you make a deposit. I have seen engineers with ordinary technical skills achieve huge results because everyone trusted them.

See also

  • DuckDuckGo
  • gogcli - a fast CLI for controlling Google Workspace from the terminal

Favorite site

Tip/Trick

  • Cutting Google out of your life - DeGoogle - cutting Google out of my life - a list of alternatives for removing Google products from a Google-dependent life

Article

  • Millions of Accounts Vulnerable due to Google’s OAuth Flaw ◆ Truffle Security Co. - Millions of accounts at risk due to a Google OAuth flaw
    • A flaw in Google's "Sign in with Google" authentication flow puts the personal information of millions of people at risk of theft.
    • Google OAuth sign-in does not stop an attacker who buys a failed startup's domain from re-creating former employees' email accounts.
    • This gives access to multiple SaaS products, and sensitive data (Social Security numbers, tax documents, etc.) can be leaked.
    • More than 100,000 domains of failed startups are currently for sale, and the number of potentially exposed accounts could exceed 10 million.
    • Google is aware of the issue but has not yet offered a fix.
author Zer0 sitemap