Titus Winters, former Google engineer (10+ years), lead author of Software Engineering at Google, and former owner of Google’s readability program, discusses engineering at scale, developer productivity, and why computer science education needs fundamental reform in the AI era.
Titus’s path to Google and early work
Grew up programming from age 11 with a QBasic book; studied at Harvey Mudd, then did a PhD in CS education at UC Riverside.
Joined Google in 2010 in New York; initially placed on a network-traffic monitoring team (databases work) that was a poor fit.
Volunteered for a new team maintaining low-level C++ infrastructure libraries written by early Googlers (employee IDs with two digits); became the only person to show up for the second meeting, effectively claiming the role.
This team owned foundational components (caches, containers, strings, command-line flags) used across Google’s entire codebase.
Google’s testing culture originated from a 2006 crisis
Around 2006, Google Search lost the ability to release on a regular cadence — down to roughly one release per quarter instead of monthly — because persistent regressions blocked every push.
The codebase was highly entangled: changes to Gmail could break Search, and almost everything had tendrils into the front end.
Release engineers drew a hard line: no merge without tests, regardless of VP pressure or feature importance; they would roll back non-compliant changes.
This forced even reluctant engineers to write tests, establishing a safety net that later enabled massive refactoring.
Abseil: the largest refactoring in human history
Around 2014–2016, Google prepared to open-source core C++ libraries (Abseil) as a common substrate for Alphabet companies and Cloud customers.
The internal codebase was ~250 million lines of first-party C++ (not counting dependencies), edited by ~10,000 engineers per month.
A team of 10–12 engineers used compiler-assisted, AST-based refactoring (Clang/LLVM) to rewrite idioms across the entire monorepo while the building stayed open — “replacing the foundation under the Empire State Building without closing it or blocking traffic.”
They built tooling to generate deterministic edits, parallelized by directory, and maintained backward compatibility during transition; clang-format was created to solve whitespace preservation during automated rewrites.
The result: external Abseil matches cleaned-up internal idioms, and engineers trust that copy-pasting existing code yields correct, modern patterns.
Readability review: Google’s scaled mentorship program
Every change requires two approvals: (1) an owner of the affected files, and (2) someone with “readability” certification in that language — proof they write idiomatic, consistent code.
Readability began as employee #3 (Craig Silverstein) personally walking each new hire through their first change; it evolved into a mentorship program where reviewers give non-judgmental feedback on normal work until the engineer graduates.
At its peak, tens of thousands of engineers participated simultaneously, making it arguably the largest educational program in tech.
It doubles as a cross-team information-sharing mechanism: reviewers see other parts of the codebase, learn new tech, and build relationships.
Software Engineering at Google book
Co-authored with Hyrum Wright and Tom Manshreck; modeled on the SRE books — experts wrote chapters, the leads edited and wrangled.
Took ~2 years at quarter-to-half time; captures Google’s hard-won lessons on monorepo, code review, testing, readability, and large-scale refactoring.
Focuses on development practices up to merge; deliberately excludes production operations (would double the length).
Teams, psychological safety, and the iterated game
Software engineering is a team sport; even with AI agents, humans manage the team of agents or use AI as a tool within human teams.
Psychological safety predicts ~30% of variance in whether a team hits its goals (per DORA research) — more powerful than any technical metric.
The iterated prisoner’s dilemma applies: optimize for long-term team growth by letting the most junior person who can handle a task do it with supervision, rather than always assigning to the expert.
Layoffs destroy psychological safety: weeks of one-on-ones become therapy sessions, people brush up résumés, and trust erodes — a massive hidden productivity cost.
Adobe avoided broad layoffs after the Great Recession because the CEO saw the cultural damage; most big tech did not learn this lesson in 2022–2023.
Developer productivity measurement and AI’s invisible value
Productivity is hard to measure because units are unclear; Adobe uses an index approach: basket positive/negative indicators (releases, test coverage, PRs, etc.), weight them via engineer pairwise comparisons, track the aggregate over time.
Four forms of impact: product success, compute efficiency, engineering capacity, and changing the game (strategic innovation).
Current metrics capture the first three but miss the fourth: AI enables doing harder, more valuable things that weren’t previously attempted (e.g., rewriting a licensed high-performance component in weeks instead of years).
A senior engineer reported: “70% more code, 30% more outages, same number of features” — the value shift is in what gets built, not volume.
AI value doesn’t show up in widget-counting metrics; we lack instrumentation for “value of this change.”
CS curriculum is stuck in the 1990s and must change
Titus was the only active software engineer on the ACM/IEEE/AAAI steering committee for the undergraduate CS curriculum (2023).
The average curriculum hasn’t substantially changed since ~2000; it teaches what was needed to build a database or OS in the 1990s.
Curriculum grows by accretion — adding topics, shaving depth — rather than deliberate design.
AI makes traditional assignments (linked lists, palindrome finders) trivial to complete without learning; the “vast middle” of students (B and below) are collapsing into prompt-copying without understanding.
Teach design, specification, testing, validation, teamwork, communication — the skills that remain valuable with AI.
First semester: unaided coding to build reading fluency and control-flow understanding.
CS0 (intro for all): interface design — checkboxes vs radio buttons, CLI flags, API structure — so even “vibe-coded” personal tools have coherent design.
Motivate theory by putting students in situations where they need the answer (e.g., “how does a web RPC work?”) before teaching it.
More team projects with critique as a graded component: evaluate others’ work and practice giving feedback without being a jerk (psychological safety).
Use AI to analyze sentiment/rudeness in peer feedback.
CS enrollment may plummet; software engineering programs (practice-oriented) will rise because those skills get jobs in the AI era.
Advice for new grads entering the industry
Don’t chase the same shiny topic everyone else is chasing; you cannot stand out that way.
Find something genuinely interesting (even weird) and go deep; you’ll have a novel story for interviews and be memorable at networking events.
Raw engineering skill matters less with AI; replace it with deep domain expertise (e.g., “engineer in embedded audio” not “C++ engineer”).
Mobility across domains may decrease because domain understanding becomes the primary differentiator.
Book recommendation
The Psychology of Software Teams by Cat Hicks — especially the “brains in jars” analogy; Titus wishes every leader had its chapters downloaded into their brain.
