▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=mQu0zN4IvSI
• Original title :: Software engineering at Google & CS education with Titus Winters

Gergely Orosz interviews Titus Winters, lead author of Software Engineering at Google. Winters spent more than ten years at Google, where he led the readability program and built Abseil, the open-sourced foundational C++ libraries. He is now a Senior Principal Scientist at Adobe working on developer experience, and was the only practising engineer on the steering committee of the ACM/IEEE/AAAI undergraduate CS curriculum guidelines. The conversation covers how Google made tests mandatory after search lost its release cadence, a semi-automated refactoring of a 250-million-line C++ codebase using compiler-based AST tooling, and the readability review as a mentoring program. Winters argues that psychological safety and learning culture predict team success better than anything else, that productivity metrics miss the main value of AI (doing harder, more valuable things), and that most of the CS curriculum has not changed since about 2000 and should be burned down in favour of specification, testing, validation, teamwork and graded process rather than code.

Background and joining Google

• Winters started programming around age 11-12 from a QBasic book his father bought instead of Valentine's candy, taught himself through high school (magnet school with a CS program in Las Vegas), then went to Harvey Mudd.
• Master's and PhD at UC Riverside in CS education (educational data mining, applied AI). The advisor was the department chair, so Winters taught many classes and learned the history of the field.
• After the PhD, four years at a small consulting startup, mostly embedded set-top box work for DirecTV (UPnP, local RPC). Took a Google offer in 2010 and was placed in New York rather than the Bay Area, driven by his wife's grad school.
• The interview went less well than he felt: he flew in the same morning to save vacation days. In one question he stubbed the basic math as a function and moved on, which the interviewer liked.
• First team was network traffic monitoring, effectively a databases problem and a poor fit. Two months in, an email asked for volunteers for a new team maintaining old low-level C++ infrastructure written by early employees. About ten raised hands, Winters was the only one to attend the second meeting and joined the team.
• Orosz pushes back that a new hire declining a team assignment sounds odd. The context is Google's rapid growth, loose headcount rules and easy team moves in 2010.

Why Google made testing mandatory

• Around 2006-2007 search lost the ability to ship on a regular cadence: monthly releases slipped to roughly quarterly because changes anywhere (Gmail included) could touch the front end or search.
• Release engineers banded together and declared that no change would be merged without tests, regardless of VP opinions or feature importance. Changes would be rolled back otherwise. Once the line was drawn, even engineers who thought tests were beneath them complied.
• By 2010 this safety net made low-level maintenance tractable: if a change passes tests it works, otherwise coverage was missing and should be added.
• Winters' principle: fear is not an acceptable basis for engineering. A codebase is sustainable if any valuable change can be made safely; the option to skip a change is a choice, not an inability. With security getting worse, the ability to change is a strategic advantage.
• Why new engineers fear making mistakes: it is either a poorly engineered system or missing onboarding and mentoring. School teaches that there is a single right answer and every look at your code is a grade, so juniors treat feedback as judgment. Experienced engineers ask for non-judgmental check-ins, and the more of that feedback they get, the more effective they are. Orosz recalls the same confusion at his first job, where lack of feedback felt like being about to be fired.

Abseil and the C++ refactoring

• Abseil started about ten years ago, after Google's pivot to cloud and the move to Alphabet. The idea was to externalize developer tools and share common internal components across companies without a single monorepo. The multi-tenant tooling idea was dropped after a year or two, but the low-level C++ layer remained.
• Abseil is the common C++ vocabulary Google code is written in. Because some of it was ugly or technical debt, the team cleaned it up before open-sourcing, ensuring external idiomatic code stays compatible with internal. Winters argues this was probably the largest refactoring task in human history: about 200-250 million lines of first-party C++ and about 10,000 engineers editing the code monthly, handled by 10-12 people. The team joked it was replacing the foundation under the Empire State Building without closing the building and finding nuclear waste in the basement.
• For scale, Orosz notes Uber's iOS and Android apps were about a million lines each, built by roughly 200 engineers over years.
• Approach: own the nuts-and-bolts interfaces (caches, containers, string routines, command line flags), then change APIs with 50,000 call sites or 100,000 edits using compiler-assisted refactoring. Clang/LLVM colleagues provided AST transformation. A MapReduce over all build targets parses each translation unit, matches specific calls in specific contexts (not text matching) and generates edits.
• White space was a blocker: edits were generated but not formatted correctly, so clang-format exists partly because Winters needed it.
• Edits are too large to land at once, because the codebase changes under them. The method: make the old and new API coexist, split the change by directory into many small batches, wait for cleanup, guard against new copies of the old pattern, then delete the old API. Done a few hundred times.
• Engineer reaction moved from "why are you changing my code" to "my code just gets better". When the codebase is constantly janitored, copy and paste becomes a reasonable answer, since a wrong pattern would already have been fixed.

AI for rewrites and deterministic tooling

• Orosz notes that today AI is the obvious tool for refactoring but feels janky compared to the deterministic Google approach.
• Winters: the deterministic approach is already spreading. In Java, OpenRewrite takes a pattern and a rewrite config, and AI is very good at generating OpenRewrite recipes, which is cheaper in tokens, more accurate, faster and auditable. He recalls talks from Netflix and Uber converging on this. A startup of friends, Brontosaurus, does declarative high-intent rewrites for C++.
• Kelsey Hightower's "zero token architecture" thesis: do not use AI for constant inference, use it to generate the deterministic tool, and use AI only for the gaps. Architecture based on permanent token consumption is more expensive and less effective.
• Orosz relays a head of engineering who runs thorough AI code reviews occasionally and has agents turn each finding into a lint rule, which is cheap and repeatable. This echoes Uber's culture of encoding architectural rules as lint rules.
• Winters agrees: learn hard lessons once, codify them in deterministic rules, and keep human review attention for the parts needing humans.

Software Engineering at Google, the book

• The book followed the push to externalize developer tools: the team needed to explain why Google's tools look the way they do, and had accumulated unusual experience with every clever solution engineers had tried at scale. Winters stresses these are development and testing scars, not production ones; the book ends at merge and does not cover operations.
• Format follows the SRE books: experts contribute chapters. Winters, Hyrum Wright and Tom Manshreck were the three authors (Wright and Winters as technical leads, tech writer Tom handling editorial and structure). Wright generated millions of edits and Winters reviewed them.
• The project took almost two years at quarter to half time, and overshot in length considerably.

Readability review

• At Google, a change needs two permissions: someone with ownership of the files, and someone certified in idiomatic style for that language in that codebase (readability). It aims for consistency and avoids reinventing the wheel.
• Originally an early employee personally walked each new hire through their first change. That did not scale and became a hazing ritual because finding a change meaty enough to prove everything was hard. Java started shifting it into a mentoring program: after team signoff, a mentor from a pool reviews for quality and norms. Teams with high standards graduate quickly, people who ignore lessons slowly.
• Winters considers it by design an education program, probably the largest in tech with tens of thousands of participants at any time. A typical progression runs from addressing comments, to wanting fewer comments, to becoming a reviewer. It also spreads knowledge across codebases.

Teams, psychological safety and AI labs

• Asked about the book's claim that lone craftspeople are rare and great teams matter, even with the rise of the "100x engineer" with agents. Winters: regardless of AI belief, the team stays critical, either as a team of agents each engineer must manage (without training for it) or as AI tools within a human team. Clear communication and writing things down still matter. Software engineering is a team sport.
• Orosz points to Claude Code: a public face, but a team that gels and runs without Boris Cherny.
• Research (DORA and others) boils down to culture, psychological safety and permission to learn. Winters cites that 30% of the variance in whether a team hits its goals can be explained by about 15 psychological culture questions, stronger than any other signal. Effective structures like lint rules and blameless postmortems are about information flow and learning.
• Recommends Cat Hicks, The Psychology of Software Teams, and a forthcoming Platform Engineering at Google book where he wrote the education chapter.
• Fred Brooks' surgical team is his least favourite chapter of The Mythical Man-Month: it treats work as a single-shot project and is hierarchical. In an iterated game, give the task to the most junior person who can do it with supervision so they grow, which requires people to admit they do not know things.
• Orosz argues AI labs get this naturally: hypergrowth, rising equity (so performance reviews matter less) and genuinely new technology where nobody knows. Companies with annual cuts of about 6% create internal competition and discourage saying "I don't know". Winters agrees that believing team outcomes drive personal success makes it easier to share work, while individualism leads to stagnation.

Layoffs and culture

• Layoffs bring weeks or months of one-on-ones that start with coping, engineers refreshing resumes and time lost to stress. Winters is skeptical that executive accounting includes this hidden cost.
• They also demotivate: extra effort buys no extra safety, which reframes the job as a business obligation instead of a lifestyle choice.
• Adobe was cited as an example. Its long-time CEO saw the damage from layoffs during the Great Recession and avoided sweeping layoffs in recent years, apart from local team-level re-prioritization.

Measuring developer productivity and AI

• Winters works on developer experience at Adobe, which he calls a polite fiction for the business of productivity, since engineering compensation is most companies' biggest cost. He criticizes the McKinsey approach to measurement.
• His idea: since units of productivity are unknown, build an index (economics-style) from many positive and negative indicators (releases, test coverage, PR counts), weighting them by running pairwise "hot or not" trade-off exercises with experienced engineers (wisdom of the crowds, like guessing jelly beans). Dedupe correlated stats and aggregate to a unitless number to track over time. Adobe is doing something similar.
• This will not capture the AI boom. The "develop, deploy, operate" paper lists four forms of impact: product success, compute efficiency, engineering productivity (capacity, not fungible money) and changing the game (strategic innovation, such as research making the impossible possible).
• AI shifts the game: the value of a change of a given size has changed (for instance, a JPEG parser can be written in a couple of weeks), but no metric tracks that. Output counts are like counting widgets when the factory now makes gold-plated ones.
• Orosz shares a story of a CTO who considered cutting half the team to reach cash flow positive, but an engineer instead used a vendor's test harness to have AI write a faster replacement for a licensed component that took a revenue share. The vendor paid them not to open source it and let them re-license it, which changed the business.
• Winters notes no research number shows post-AI productivity above about 20-30%, yet people claim 10x. He cites a senior engineer's numbers: 70% more code, 30% more outages, same number of features. The unknown is whether the value of those features went up. The value of AI is doing harder things, not the same things faster.

Rethinking CS education

• Winters was the only active engineer on the ACM/IEEE/AAAI undergraduate curriculum steering committee and managed mostly the software engineering requirements. His view: most of the CS curriculum has not substantially changed since about 2000 or earlier. The average topic is what was needed to build a database or operating system in the 1990s, taught out of tradition or because it is teachable.
• Curricula grow by accretion: more topics added and depth cut by epsilon. Even pre-AI he wanted more practice and drill to produce fluent programmers instead of trivia knowledge of many topics.
• A whole undergraduate degree can now be done by feeding assignments to AI. Winters wants to get out of the code and up-level: reading code and systems thinking, design and specification, precision in saying what should happen, and testing, validation and verification. No one needs to implement a linked list.
• He expects CS enrollment to plummet while software engineering programs grow, since teamwork, communication, design, specification and testing are what will matter.
• Orosz argues for a software engineering degree where projects chain (build, team build, extend) and recalls only one team class in his CS degree, so real-world work felt like starting from scratch with theory but no reps.
• Winters adds that LeetCode-style interviews were a proxy for time on task: those who played in programming contests had put in reps. A CS degree amounts to about 15 months of full-time work, not far from a six-month boot camp that is laser-focused on relevant skills.
• Orosz notes Waterloo (four co-op placements) as a strong model; many Canadian programs run five years with co-ops. Winters wishes for more projects but is wary of a single project course, because real teams never consist of people with identical background.

What new grads should learn

• Nobody agrees what "the basics" are. Kent Beck said recently that all current workers grew up with a playbook, and there is none now.
• Juniors should avoid copying tickets into prompts and shipping the result: that can be replaced by a short script. Use AI to widen inputs and better yourself, not to produce all outputs. "Andrew's Axe" metaphor: the person chops the tree, the axe is a tool. A 1979 IBM manual said a computer cannot be held accountable, so the engineer's name on a pull request means accountability and rigor.
• Professors report a split: the best students (B+ and above) are better than ever with an infinitely patient tutor, the worst can now produce slop, and the vast middle has collapsed, relying on AI without building understanding. Winters worries students below B may not understand how code works and the system does not track that.
• Prohibiting AI is nonsense, comparable to banning compilers. A new grad who has not used AI tools is a red flag. Winters co-published a piece in Communications of the ACM that imagines 2040 with AI-native graduates and asks what traditional questions (palindromes, rainfall volume) still teach.
• Assessment: assume AI use and set learning objectives at a higher level. Orosz notes interviews that work are paired sessions where the candidate uses AI and explains what and why. Winters adds oral exams, and above all grading process instead of outcome: the prompts used and the tests provided, the whole package as evidence of struggle and learning, as the artifact (essay, linked list) used to be a proxy for effort.

Winters' ideal software engineering curriculum

• First semester unaided by AI, until students can read code and understand control flow. Then well-scaffolded AI for education that does not hand out answers, with assessment of the whole creation process. Winters admits nobody knows what works.
• CS zero for majors and non-majors: describing inputs, outputs and interface design (checkbox versus radio button, button versus other widget, command line flags, positional parameters) so that vibe-coded tools for personal use have a coherent design language. Example: the laundry room app in his condo that uses a menu instead of a button.
• Then projects and teamwork, motivating students to want to solve bigger problems, so that theory (how the web or an RPC works) answers a need they feel instead of being isolated trivia.
• More projects without a single correct answer, with part of the grade for critiquing others' code or outcomes and for giving feedback without being a jerk (reflecting psychological safety). AI can assist with sentiment analysis of reviews.
• Winters expects this to happen in software engineering departments rather than CS departments.

Advice for breaking into tech

• Most of Winters' success came from not doing what everyone else does. Standing out by chasing the same hot topic is very hard. Find something genuinely interesting, preferably weirder than peers' work, and invest time, which gives a novel story for interviewers and founders.
• With AI-assisted engineering, raw engineering depth matters less and depth in the problem domain matters more, which may reduce mobility: not "a C++ engineer" but "an engineer in embedded audio".
• Book recommendation: The Psychology of Software Teams by Cat Hicks, especially a couple of chapters (the brains in jars analogy) he wishes every leader had in their head.

Orosz's takeaways

• The 250 million lines of C++ were pre-AI. The deterministic approach of parsing code, matching patterns and generating edits may still be more reliable than non-deterministic AI refactoring, though harder to build.
• The value of AI is being more ambitious and doing harder things, not doing the same things faster.
• CS programs need to become much more practice oriented or enrollment will fall, and industry people should get involved in refreshing the software engineering curriculum.