Software engineering at Google & CS education with Titus Winters

Summary of Software engineering at Google & CS education with Titus Winters

by Gergely Orosz

1h 40m•October 29, 2026
Listen to Episode

Overview of Software engineering at Google & CS education with Titus Winters

Gergely Orosz interviews Titus Winters, former Google engineer, co-author of Software Engineering at Google, and a key voice in computer science curriculum design, about what it takes to build and maintain software at massive scale, how Google evolved its engineering culture around testing and readability, and why AI is exposing the limits of today’s productivity metrics and CS education. The conversation centers on a big idea: software engineering is fundamentally a team sport, and both industry and academia need to shift toward more explicit practices around testing, design, feedback, and learning.

Key Themes and Takeaways

Google’s engineering culture was shaped by real pain

  • Google’s strong emphasis on tests wasn’t abstract theory; it came from production pain.
  • Around 2006, the flagship search product could no longer ship regularly because regressions were too common.
  • Google’s response was to make tests mandatory: if a change lacked tests, it simply would not merge.

Engineering at Google focused on making change safe

  • Titus describes sustainable codebases as those where valuable changes can be made safely.
  • The goal is not to eliminate change, but to ensure the organization can react to change without fear.
  • If engineers are afraid to touch a codebase, that’s a sign of either technical debt or weak onboarding/mentoring.

Google’s scale made maintenance its own discipline

  • Titus worked on low-level C++ infrastructure and later on large-scale refactoring efforts.
  • Google’s internal codebase was enormous—on the order of hundreds of millions of lines of C++.
  • The team used compiler-assisted refactoring techniques, especially AST-based transformations, to make large rewrites feasible and safe.
  • A major lesson: deterministic tooling beats ad hoc manual editing when you need to update code at massive scale.

Abseil and readability were about standardizing good engineering habits

  • Abseil emerged as a way to expose Google’s internal C++ “vernacular” and clean it up for broader use.
  • The readability program ensured that code wasn’t just functional, but idiomatic and maintainable.
  • Readability review became a mentoring and education system, not just a gatekeeping step.
  • Titus sees this as one of the largest educational systems in tech: tens of thousands of engineers learning through code review norms.

Google, AI, and Developer Productivity

AI changes the nature of productivity measurement

  • Titus is skeptical that today’s productivity metrics capture the real value of AI.
  • If AI helps teams do the same work faster, existing metrics may show only modest gains.
  • But AI’s real value may be in enabling teams to attempt harder, more valuable work that wasn’t previously practical.

Productivity is more than output

Titus breaks impact into four categories:

  • Product success — revenue, usage, customer outcomes
  • Compute efficiency — infrastructure and cost savings
  • Engineering capacity — more useful engineering work done with the same headcount
  • Strategic change — AI enabling entirely new kinds of solutions

Deterministic tools still matter more than raw AI

  • Titus argues that AI is best used to help generate deterministic tooling, not as the final solution itself.
  • Examples include:
    • AI generating rewrite rules
    • AI-assisted lint rules
    • Declarative refactoring tools such as OpenRewrite-style workflows
  • The recurring lesson: write the rule once, then automate it reliably.

Software Engineering Is a Team Sport

Individual heroics are not enough

  • Titus strongly rejects the idea that software engineering is mostly about lone genius work.
  • Even “superstar” engineering outcomes depend on teams, trust, communication, and shared learning.

Psychological safety is a performance multiplier

  • Teams do better when people can admit uncertainty and ask questions without fear.
  • Titus points to research suggesting culture can explain a meaningful portion of team success.
  • Blameless postmortems, clear feedback loops, and learning-oriented norms are not soft extras—they’re performance infrastructure.

Layoffs damage more than morale

  • Layoffs create hidden costs:
    • stress
    • resume polishing
    • reduced focus
    • less experimentation
    • weaker trust
  • Titus notes that companies often underestimate the productivity loss that follows layoffs.

How CS Education Needs to Change

The current curriculum is overdue for a reset

  • Titus, who served on the ACM/IEEE curriculum steering committee, says much of the CS curriculum still reflects the needs of the 1990s.
  • He argues that the curriculum has grown by accretion rather than design.
  • In his view, some of it should be “burned down” and rebuilt around modern realities.

AI makes traditional assignments less meaningful

  • If students can solve standard assignments by prompting AI, then those assignments no longer prove competence.
  • Titus argues CS programs should move away from grading only the final artifact.
  • More emphasis should be placed on:
    • prompts used
    • tests written
    • validation and verification
    • design decisions
    • critique and feedback quality

Focus on software engineering, not just computer science theory

He wants education to emphasize:

  • specification
  • teamwork
  • code reading
  • testing
  • communication
  • system design
  • review and critique
  • iterative development

Practical experience should start much earlier

  • Titus is especially critical of programs that offer too little real software-building practice.
  • He points to co-op-heavy programs like Waterloo as stronger models because students graduate with meaningful industry experience.
  • His ideal curriculum would have students building software from early on, in teams, with real feedback cycles.

Advice for Students and New Grads

Don’t just copy-paste AI outputs

  • Using AI effectively means improving your thinking, not outsourcing it.
  • If your workflow is only “paste ticket into prompt, paste answer into PR,” you are not building defensible skill.

Learn to own the problem

  • Titus recommends developing:
    • judgment
    • resilience
    • domain depth
    • attention to detail
    • willingness to learn in public

Stand out by going deeper, not broader

  • His advice to students: do something genuinely interesting and unusual.
  • The best opportunities often come from being memorable and having a real story—not from chasing whatever everyone else is doing.

Domain expertise may matter more than generic coding

  • In an AI-assisted world, raw coding skill may matter less than deep understanding of a problem space.
  • Titus suggests future engineers may differentiate themselves through domain specialization, such as embedded audio, security, or another concrete area.

Notable Quotes and Ideas

  • “Fear is not an acceptable basis for engineering.”
  • “Software engineering is a team sport.”
  • “The value of AI is not just doing the same thing faster—it’s doing harder things we wouldn’t have attempted before.”
  • “Write the rules once, then spend human attention only where it matters.”

Bottom Line

This episode is both a retrospective on how Google built engineering systems that could scale safely and a forward-looking critique of how software education and productivity measurement need to evolve in the AI era. Titus Winters’ core message is consistent throughout: strong engineering comes from learning systems, safe change, good feedback loops, and teams that can adapt. AI is not replacing those fundamentals—it makes them more important.