Titus Winters on Software Engineering, Teams and CS Education

Gergely Orosz speaks with Titus Winters about software engineering at Google, large-scale C++ refactoring, team culture, developer productivity and computer science education. Winters’ comments about AI and curricula are his perspective and predictions.

Winters describes his background in computer science education and his route through consulting to Google. He was drawn to developer efficiency, API design and low-level systems.

His initial Google assignment was not an ideal fit, but he eventually moved toward C++ infrastructure. The conversation highlights the importance of finding a team where an engineer’s strengths match the work.

Winters recounts how release engineers insisted on tests for changes when frequent releases were difficult. Tests made it safer to modify shared code and helped teams move more confidently; his story describes a particular historical context.

New engineers may fear breaking production because a system is fragile or onboarding and mentoring are insufficient. Winters says education can reinforce the mistaken expectation that every engineering problem has one correct answer rather than tradeoffs.

He discusses Abseil and the need to share foundational C++ components across different contexts. Making internal tools and interfaces usable elsewhere raised questions about dependencies and compatibility.

The team faced a large refactoring across what Winters estimates was 200–250 million lines of first-party C++ code, with many engineers changing the code at the same time. He compares the task to replacing a building’s foundation while it remains open.

Text search alone was not enough to safely identify every relevant call. The team used compiler-aware transformations of abstract syntax trees to match code by structure and generate edits.

Formatting generated changes was a practical obstacle. Winters connects the need for an automatic C++ formatter with that work; the team also had to divide changes into manageable batches while the codebase continued moving.

He argues that maintaining consistent code improves the examples future engineers copy. A continuous cleanup capability can make the existing codebase a more trustworthy source of patterns, though copied code still needs review.

The speakers compare deterministic refactoring tools with AI-assisted rewrites. A compiler-based transformation can provide precise matches for a defined change, while AI may help generate tools or handle cases that are harder to formalize.

They discuss using AI to discover a recurring review problem and then encoding that check as a repeatable lint rule. This may reduce repeated inference cost and make an established rule more consistent, subject to the rule’s own correctness.

Winters explains the origins of Software Engineering at Google: engineers who had repeatedly encountered large-scale design and maintenance problems assembled lessons with help from subject experts. The book describes practices at a particular time, not permanent rules for every organization.

Google’s readability review paired code ownership approval with language-specific expertise. Over time, Winters says, the process evolved from a one-off demonstration into mentoring across ordinary changes.

A mentor reviewed changes after the team’s own review and gave feedback about idiomatic, consistent code. Engineers could progress toward certification and eventually mentor others; the process also spread knowledge across teams.

Asked whether powerful AI tools reduce the importance of teams, Winters says coordination and clear communication still matter. Even an engineer directing agents must specify work, review outcomes and collaborate with people.

He links effective teams to information sharing and permission to learn. Psychological safety makes it easier to admit uncertainty, discuss mistakes and improve the system rather than conceal problems.

For a recurring team, assigning a supervised junior engineer an appropriate task can build future capability. Winters contrasts that with optimizing a single project only for the immediately fastest individual.

The speakers discuss how performance pressure and internal competition can discourage knowledge sharing. Winters argues that when people trust team success to support their own success, they can invest more in one another’s growth.

He describes the stress and lost focus surrounding layoffs, including time spent supporting colleagues and preparing for uncertainty. This is a qualitative account of organizational costs, not a quantified causal estimate.

On developer productivity, Winters describes combining multiple indicators—such as releases, tests and changes—rather than treating one number as the whole story. Any composite measure depends on its inputs, weights and context and can be misused.

He distinguishes doing the same work faster from changing what is feasible. AI may enable a team to attempt a project that previously seemed uneconomic; a throughput metric alone may miss the value of that change.

The host shares an example of a team using specifications and tests with AI to replace a costly component. The anecdote illustrates a possible change in economics, not a guarantee that an unreviewed rewrite is safe or correct.

Winters served on a professional-society curriculum effort and argues that much undergraduate computer science content has changed too slowly. He asks whether topics remain because they are essential, because of tradition or because they are easy to teach.

He proposes putting more emphasis on design, precise specifications, testing and verification alongside teamwork and communication. His prediction about shifts in degree enrollment is speculative, and the appropriate balance of theory and practice remains debatable.

The speakers compare degree programs with intensive practical training and cooperative placements. Real experience can help students learn version control, reviews and working with others, while foundational theory can also be valuable.

Winters advises junior engineers to use AI to broaden understanding rather than simply paste a ticket into a prompt and submit the output. People remain responsible for specifying and verifying work even when tools generate code.

He questions attempts to ban AI outright in education while acknowledging that students can bypass the learning process. The challenge is to design assessment that reveals understanding, not merely whether a final artifact exists.

Possible approaches include oral explanation, pairing and evaluating the process used to reach an answer. The speakers acknowledge that educators are still experimenting and that there is no settled playbook.

Winters imagines an introductory course on expressing interfaces, inputs and outputs clearly before focusing narrowly on implementation. He wants students to learn how to make tools produce work fit for a real purpose.

For people entering the field, he recommends pursuing a genuine interest and developing a distinctive body of work rather than following every fashionable topic. The host closes by reflecting on deterministic tools and the value of changing what teams can build.