Lessons from 14 years at Google

Overall reception of the lessons

• Many commenters find the list highly insightful and broadly applicable beyond Google, especially around user focus, clarity over cleverness, and novelty as “debt.”
• Others see it as generic “LinkedIn-style” advice that adds little beyond what experienced engineers already know. Several say it’s valuable mostly if you write your own version from your own career.

Shipping fast vs quality

• “Bias toward action / ship early” resonates with people who’ve seen progress blocked by blank pages and over-planning. They note early shipping exposes hidden organizational friction.
• Strong pushback: in many orgs this slogan is misused to justify shipping broken, low-quality products and never cleaning up. Some argue it entrenches bad incumbents and worsens overall software quality.
• Several advocate a middle path: ship something small but correct and minimal; don’t confuse speed with sloppiness.

Novelty, abstraction, and complexity

• The “novelty is a loan” and “abstractions move complexity” lines get repeated a lot. Many tie them to “boring tech,” innovation tokens, and Joel Spolsky’s leaky abstractions.
• Some argue good abstractions do reduce effective complexity by localizing it and letting most people work at higher, clearer levels. The real problem is premature or fashionable abstraction.

User focus vs Big Tech reality

• The claim that the best engineers are obsessed with user problems is widely agreed with in principle, but multiple ex-Googlers say this was not the norm inside Google:
  • Engineers talking directly to users or reading support forums were considered odd or even discouraged.
  • UX of major Google products is heavily criticized as clumsy and regressing over time.
• Several note that in big orgs “customer” often means OEMs, advertisers, or internal stakeholders, not end users.

Bugs, ossification, and socio-technical systems

• “At scale, even your bugs have users” triggers many stories: users depending on slow load times for coffee breaks, on specific timing quirks, on noisy 5V rails, on inefficient CPUs that didn’t spin fans.
• Hyrum’s Law and protocol ossification are cited: anything observable becomes a de facto contract, so “fixing” issues can break real workflows.
• This leads to emphasis on understanding real-world use, not just specs or tickets.

Careers, politics, and recognition

• The points about “your code doesn’t advocate for you,” “glue work,” and “winning every debate breeds silent resistance” generate strong discussion.
• Many describe performance systems in large companies as vibes- and popularity-driven, systematically disadvantaging less socially fluent engineers.
• Several senior folks argue politics and relationship management are inescapable; others see this as evidence big-company incentives are broken.

AI-written tone and credibility concerns

• Numerous commenters say the article and especially the bio read like LLM-assisted “slop,” full of parallel slogans (“It’s not X, it’s Y”).
• This raises meta-anxiety: if even thoughtful posts are AI-polished and heavily self-promotional, how much trust and originality remains?
• Past plagiarism controversy and the self-aggrandizing bio further erode trust for some, who see the piece as career-branding more than hard-won wisdom.

Are these lessons new?

• Several note that nearly all these ideas appear in classic software-engineering literature (Brooks, Parnas, Dijkstra, Conway, Goodhart, etc.).
• The repeated rediscovery is seen as evidence that:
  • The underlying constraints are real and persistent.
  • Modern incentive structures make them hard to act on, so each generation has to relearn them the hard way.