Working on complex systems: What I learned working at Google

Scale vs. Complexity

  • Several commenters stress that most projects are not at Google scale but can still be genuinely complex (e.g., game engines, logistics, enterprise integrations).
  • Others argue “complex” is orthogonal to “large”: small systems can be conceptually hard; large systems can do relatively simple things.
  • Some push back on developers copying FAANG-style architectures for tiny workloads (“cargo culting”), noting Google’s architecture is a response to scale, not a recipe for success.

Complex vs. Complicated / Types of Complexity

  • Multiple threads debate the article’s complex/complicated distinction and note overlaps with established notions: essential vs. incidental complexity, domain vs. accidental/environmental complexity.
  • Critics say the article doesn’t clearly separate:
    • complexity you choose (architecture, tools),
    • complexity imposed by the domain (logistics, manufacturing, regulations, human behavior).
  • Examples like electronic proof-of-delivery in logistics highlight socio-technical, behavioral, and infrastructural constraints as true “complexity,” not just big codebases.

Life Inside Google: Organizational Complexity

  • Commenters describe “collaboration headwind”: many approvals, domain owners, and process layers turning trivial changes (e.g., button text) into months of work.
  • A common claim is that much effort goes into fighting incidental organizational complexity rather than pure technical difficulty.
  • One perspective defends stricter process and testing as rational in a large org with high downside risk; others see it as demoralizing and leading to workarounds instead of improvements.

Testing, Code Ownership, and Friction

  • There is an extended back-and-forth on code review expectations:
    • Some reviewers insist on adding or backfilling tests before accepting even obvious fixes.
    • Contributors find it unreasonable when asked to introduce full test suites into untested code just to land a small change.
    • Others argue this is exactly what professional engineering should require; untested changes are seen as liabilities.

Incentives and Peer Bonuses

  • Peer bonus systems are described as “tips” funded by the company, intended to reward extra help.
  • Some see them as positive and motivating (especially when paid in cash); others view them as gamified, low-value recognition that substitutes for real raises or PTO.

Google, Games, and Product Judgment

  • Discussion notes Google’s failed or shuttered gaming efforts (e.g., Stadia) and past work via Niantic.
  • Several argue Google and also mobile platform owners struggle to understand the games industry and tend to push complexity onto developers.

Meta and Miscellaneous

  • Multiple people point out the irony of a buggy, reappearing cookie banner on an article about complex systems.
  • Others reference systems thinking (Meadows, Cynefin, complex systems literature) and appreciate the topic but criticize redefining established terms or glossing over long-standing research.