TL;DR
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
The Pragmatic Engineer published a podcast interview with Titus Winters about large-scale engineering at Google and the future of computer science education. Winters discussed a 250-million-line C++ refactor, testing and code review practices, and the limits of measuring AI productivity; several claims in the interview are his recollections or observations, not independently verified findings.
The Pragmatic Engineer has published a podcast interview with Titus Winters, a former Google engineer and lead author of Software Engineering at Google, covering the company’s large-scale software practices and the need to rethink computer science education. The discussion matters to engineering teams and educators because it links reliable code changes, developer training and AI-assisted coding to questions about software quality and what new engineers should learn.
Winters spent more than a decade at Google, where he led the company’s readability program and helped build Abseil, an open-source collection of foundational C++ libraries. He is now a senior principal scientist at Adobe, working on developer experience and productivity, according to the podcast’s introduction. The conversation ranges from a major C++ refactor to undergraduate curriculum guidelines developed through the ACM and IEEE.
One example Winters described was a cleanup project begun in 2010, involving a Google codebase he said was then close to 250 million lines of code, edited by about 10,000 engineers. A team of roughly a dozen people used automated parsing and code generation to identify and update patterns across the code. The source says the work also involved running old and new APIs side by side, distributing changes in batches and then removing the old API. It credits the project’s needs with prompting the creation of the clang-format toolkit.
Winters also recounted Google’s decision to require tests alongside code changes after Search’s release cadence slowed. He said that around 2007, the product could be shipped only quarterly, and that a company-wide requirement for tests accompanied every change. The interview says Search later returned to a faster cadence, though it does not provide dates or measurements for that recovery. Google’s code review system, as described in the episode, also paired project owners with reviewers certified in language readability; Winters said more than 10,000 engineers were enrolled in that program when he left Google.
Why Safety Practices Shape Output
The discussion puts a practical question behind debates about engineering speed: how much code can teams safely change, not simply how much they can produce? Winters argues that testing, review and other safeguards make valuable changes less risky. That perspective is relevant as AI tools increase the volume of code developers can generate: more output does not necessarily mean more completed features or better software.
Winters shared an observation from conversations with engineers at other companies: they were seeing substantially more code output than a year earlier, alongside outages he estimated were up about 30%, while feature delivery remained static. That figure is his reported observation, not a sourced industry-wide measurement; the excerpt gives no sample, timeframe beyond the year-on-year comparison, or method. Even with those limits, the contrast highlights why productivity assessments should track reliability and shipped work, not code volume alone.
For educators, the interview raises a related issue: whether undergraduate programs are preparing students for modern software work. The episode describes Winters’ involvement in revising ACM/IEEE curriculum guidelines, but the source excerpt does not specify the proposed course changes. Its central implication is that computer science education and professional engineering practice should account for maintaining and changing large systems, alongside teaching how to write software.
Popular right now
Dyson V8 Cyclone Cordless Vacuum
Apple AirPods Pro 3 Wireless Earbuds with Active Noise Cancellation
TCL QM64L 85-Inch QD-Mini LED 4K Smart Fire TV
As an affiliate, we earn on qualifying purchases.
From Google Refactors to Curriculum
The interview connects several points in Winters’ career. At Google, he worked on infrastructure and engineering practices at a company with a very large, shared codebase. The refactor he described was not a matter of manually editing files one at a time: the team parsed build targets into syntax trees, matched specific patterns and generated edits. This approach allowed the work to be divided across directories while old and new interfaces operated together.
The episode also describes code review as a form of ongoing instruction. In the account, Google’s readability reviewers checked whether changes followed language-specific standards, while project owners supplied local knowledge. The program grew from early mentoring practices into a formal system across languages. The host characterizes it as potentially one of the largest educational programs in technology, but the source does not establish that comparison independently.
Winters’ title at Google’s book, Software Engineering at Google, reflects the broader subject: engineering processes around code, not just programming techniques. The podcast extends that focus into curriculum design and AI. The source excerpt introduces these themes but does not include the complete interview or all of the host’s listed takeaways, so it cannot support a full account of Winters’ recommendations for courses or AI use.
“We were replacing the foundation of the Empire State Building. We were not allowed to close the building or block traffic. Oh, and we discovered nuclear waste in the basement.”
— Titus Winters, recalling the Google refactor
Limits of the AI Productivity Figures
The source is a podcast and accompanying editorial summary, not a research paper or independent audit. Winters’ estimate of outages rising about 30% reflects what he said he had heard from engineers at other companies. The excerpt does not identify those companies, define an outage, specify the number of organizations or explain how the estimate was calculated. It should not be read as a verified industry-wide statistic.
Other details also remain unverified in the material provided. The source gives approximate figures for Google’s codebase and staffing during the refactor, but no underlying project records. It says tests became mandatory and Search later recovered a faster shipping cadence, without documenting the exact policy date or cadence. The excerpt also does not spell out the proposed revisions to the ACM/IEEE curriculum or provide a complete account of Winters’ views on AI’s benefits.
Curriculum Changes and Further Evidence
The immediate next step for readers is the full podcast and transcript, which The Pragmatic Engineer says are available through its YouTube, Apple and Spotify channels. The supplied report does not announce a specific rollout date for revised ACM/IEEE curriculum guidance, nor does it identify a formal next milestone in that process.
For claims about AI and engineering productivity, stronger conclusions would require data that defines code output, outages and shipped features across a stated period and a clear group of organizations. Until such evidence is available, Winters’ account is best understood as an experienced engineer’s warning that increased coding volume may coexist with reliability problems—not as a settled measurement of AI’s net effect.
Key Questions
What is the news about Titus Winters?
The Pragmatic Engineer published a podcast interview with Winters about his Google engineering work, computer science education, AI and developer productivity.
What did Winters say about Google’s C++ refactor?
He described a project begun in 2010 to update code across a codebase he said was close to 250 million lines. The team used parsing and code generation to automate parts of the change while Google’s systems remained in use.
Did the interview prove that AI is causing more outages?
No. Winters reported hearing from engineers at other companies that outages were up about 30% as code output increased, but the excerpt provides no methodology, sample or independent verification. It is an attributed observation, not proof of a broad causal effect.
What did Google’s readability program do?
As described in the interview, code changes were reviewed by a project or file owner and by a language-specific readability reviewer. Winters said more than 10,000 engineers were enrolled when he left Google.
What changes to computer science education were proposed?
The interview discusses Winters’ work on updating ACM/IEEE undergraduate computer science curriculum guidelines, but the provided source excerpt does not detail the specific proposed changes.
Source: newsletter.pragmaticengineer.com
