与 Titus Winters 谈 Google 软件工程经验与 CS 教育改革

简要描述Brief Description

Titus Winters 谈论了 Google 的工程实践、大规模 C++ 重构、可读性辅导计划、团队学习、开发者生产力，以及 AI 应如何改变软件工程教育。Titus Winters discusses engineering at Google, large-scale C++ refactoring, the readability mentoring program, team learning, developer productivity, and how AI should change software engineering education.

目录Table of Contents

• 开场亮点、赞助商与职业生涯早期阶段
  Opening highlights, sponsors, and early career
• 测试、可持续变更与工程反馈
  Testing, sustainable change, and engineering feedback
• Abseil 与如何安全地重构数百万行代码
  Abseil and refactoring millions of lines safely
• 赞助方与工程经验的制度化 രേഖ?
  Sponsors and codifying engineering lessons
• 撰写《Google 软件工程》及可读性指导
  Writing Software Engineering at Google and readability mentoring
• 团队、心理安全与学习
  Teams, psychological safety, and learning
• 裁员对工程文化的隐性代价
  Layoffs and the hidden cost to engineering culture
• 开发者体验、生产力与人工智能的价值
  Developer experience, productivity, and the value of AI
• 重新思考计算机科学与软件工程教育
  Rethinking computer science and software engineering education
• 借助人工智能学习、评估与实践性课程设计
  Learning with AI, assessment, and practical curriculum design
• 职业建议、领域专业知识与总结感悟
  Career advice, domain expertise, and closing reflections

开幕集锦、赞助商与职业生涯早期Opening highlights, sponsors, and early career

那可能是人类历史上规模最大的重构任务。当时有两亿或两亿五千万行 C++ 代码，其中两亿五千万行是自有代码，不包括外部依赖；当时大概有一万名工程师，在一个月内对这套代码库进行了修改。什么是可读性审查？我离开 Google 时，算是可读性计划的总负责人。那可能是科技行业规模最大的教育项目，因为在任何一个时刻，都有数万人参与其中。大多数计算机科学课程自 2000 年以来，甚至更早以来，都没有实质性变化。课程里讲的内容，基本正是 90 年代构建数据库或操作系统所需要的知识。That was probably the largest refactoring task in human history. It was 200 or 250 million lines of C++ code with 250 million lines of first-party, not counting external dependencies, and 10,000 engineers probably at the time making edits to that code base in a month. What is readability review? When I left Google, I was kind of the overarching owner for the readability program. That might be the largest educational program in tech cuz there were tens of thousands of people participating in that at any given moment. Most of the CS curriculum hasn't substantially changed since 2000, maybe earlier. The average thing in the curriculum is exactly what was needed to build a database or an operating system in the '90s.

这听起来不太妙，不是吗？对于一个以创新为傲的领域来说，更是如此。我一直在推动的一件事，就是我们需要跳出代码本身。我们需要大幅提升层次。计算机科学专业的入学人数会急剧下降，但软件工程专业的入学人数会大幅上升，因为说实话，在人工智能时代真正重要、还能让人找到工作的东西是——That doesn't sound good, does it? Not for a field that prides itself on innovation. A lot of what I'm pushing for is we need to get out of the code. We need to up-level substantially. CS enrollment is going to plummet, but software engineering programs are going to kick up because, let's be honest, the stuff that's going to matter in a AI era and still get a job is

如果一位参与制定当今软件工程课程内容的工程师说，这些课程大多都该推倒重来，会怎样？确实有一位软件工程师就这么说了。2023 年，Titus Winters 是 ACM 和 IEEE 本科计算机科学课程指导委员会中唯一一位仍在职的软件工程师。此前，他在 Google 工作了 10 多年，是《Google 软件工程实践》一书的主要作者，还负责运营公司的代码可读性计划。在今天的对话中，我们会探讨：为什么 Google 大约在 2006 年开发了 Test Manager——当时，由于持续出现回归问题，旗舰搜索产品已无法按固定节奏发布；衡量开发者生产力的方法，以及为什么 AI 的价值没有体现在我们如今衡量的指标中；还有 Titus 会如何改革计算机科学教育，包括为什么他希望学生的评分依据是提示词和测试，而不是代码。What if an engineer who helped define the contents of today's software engineering curriculum said that most of this should be burnt down? An actual software engineer says exactly this. In 2023, Titus Winters was the only active software engineer on the steering committee for the ACM and IEEE undergraduate CS curriculum. Before, he spent more than 10 years at Google, was the lead author of the book Software Engineering at Google, and ran the company's readability program. In today's conversation, we discuss why Google made Test Manager around 2006 after the flagship search product could no longer be released on a regular cadence due to persistent regressions. Ways to measure developer productivity and why the value of AI does not show up in the metrics that we measure today. Ways that Titus would change computer science education, including why he'd want students to be graded on their prompts and tests, not the code.

还有更多。如果你想了解 Google 在大规模工程方面积累了哪些经验，或者在 AI 时代，现代计算机科学教育应该是什么样子，那就别错过这一期。本期节目由 Turbo Buffer 赞助。Turbo Buffer 是基于对象存储构建的向量搜索和全文搜索服务，速度快、成本低，而且扩展性极强。在开始之前，我想聊聊本季赞助商 Linear。直到最近，我还以为 Linear 只是一个帮助规划和组织工作的工具，但它远不止于此。许多团队用 Linear 将变更从构思一路推进到在 GitHub 中合并，全程无需离开 Linear。我和 Linear 团队的一位工程师 Dima 坐下来聊了聊，看看 Linear 内部的开发者如何用 Linear 来打造整个 Linear。先来看一个实际问题：当你提交评审时，如果还有未发送的草稿评论，Linear 会提醒你，但不会告诉你这些草稿在哪里。And more. If you want to know what Google learned about engineering at scale or how modern computer science education should look like in the age of AI, this episode is for you. This episode is presented by Turbo Buffer, vector and full text search built on object storage. It's fast, cheap, and extremely scalable. Before we start, I'd like to talk about Linear, our season sponsor. Until recently, I was thinking of Linear as a tool that helps plan and organize the work, but it's much more than that. A lot of teams use Linear to ship changes from idea to merge in GitHub, all without leaving the tool. I sat down with Dima, an engineer on Linear team, to see how devs inside of Linear use Linear to build all of Linear. So, here's a real issue. When you submit a review with unsent draft comments, Linear warns you about these comments, but it doesn't tell you where those drafts are.

一位客户提出了投诉，Dima 决定着手解决。在修复之前，Dima 没有打开 IDE，而是打开 Linear，向智能代理描述了这个问题。智能代理完成了修复、创建了一个 PR，并附上 Storybook 截图，方便验证。你可以在截图上看到关联的修复内容和草稿评论。PR 中还有一个 Vercel 预览。你可以直接在 Linear 中一键打开预览，体验这项改动，我们看到它确实奏效了。 我最喜欢的部分是「引导式评审」，目前这项功能仍在开发中。「引导式评审」是一种全新的代码评审体验，重要内容会一目了然。评审页面顶部会显示改动摘要和示意图，而拉取请求则被划分为多个章节，带你逐步了解改动内容。这些内容块会突出显示重要改动，让人更容易理解和评审。A customer complained and Dima decided to fix it. Before the fix, Dima did not open his IDE. Instead, he opened up Linear and described the issue to the agent. The agent built a fix, created a PR, and attached Storybook screenshots for easy verification. You can see the fix with the draft comments linked on the screenshot. In the PR, there's a Vercel preview. You can open the preview with one click from Linear to play around with the change, and we see that it worked. And here's my favorite part, guided reviews, which is work in progress. Guided reviews is a new code review experience where the important stuff just pops out. The top of the review has a summary and diagram of the change. And the pull request is divided into chapters that walk you through what's changed. These blocks highlight the important changes in a way that's easier to understand and review.

哦，对了，Dima 完成这一切后，还自行批准了代码，并将其合并到 GitHub，全程没有离开 Linear。如果你只记住一件事，那就是：Linear 不再只是规划工单和组织工作的地方。所有工作都在这里完成：创建问题、启动智能体、查看预览、进行评审，以及合并到生产环境。Linear 是为团队和 AI 智能体打造的产品开发系统，我很喜欢它的这一演进。去 linear.app/pragmatic 看看，还能获得 6 个月的试用期。Titus，欢迎来到播客。Oh, and when Dima's finished with all of this, he just self-approved the code and it's merged into GitHub, all without leaving Linear. If you take one thing away from this, Linear is no longer just a place for planning tickets and organizing the work. It's where all the work happens, creating the issue, kicking off the agent, checking out the preview, doing the review, and merging to production. Linear is the product development system for teams and for AI agents, and I'm loving this evolution. Check it out and get a 6-month trial at linear.app/pragmatic. Titus, welcome to the podcast.

非常感谢你邀请我来。我特别期待这次交流。能再次面对面聊聊，真是太棒了。是的。嗯，确实很开心。那么，你是怎么进入科技行业的？你成长过程中，就知道自己将来会从事与电脑相关的工作吗？Thank you so much for having me. I'm so excited to have this one. It's It's awesome to do this in person again. Yes. Yeah, it's a joy. So, how did you get into tech? Did growing up did you know that you're going to do something with computers?

我是说，在我最早的记忆里，我觉得自己长大后会当科学家。不过你知道，对一个三岁的小孩来说，这大概就是穿白大褂、摆弄试管之类的，我也说不清还有什么，对吧？我爸很有远见，他知道电脑会很重要。那完全不是他的专业领域。他做的有点像木工、舞台布景设计之类的工作。所以家里一直都有一台电脑。通常都是比较低端的那种，就是我们想办法凑钱买得起的东西。呃，我记得自己真正起步的时候大概是十一二岁。有一年情人节，他没有给大家买糖果，而是去了书店。我不记得我哥哥拿到了什么，但我拿到了一本《学习 QBasic》。从那以后，我就一发不可收拾了。接下来的大概五六年里，我一直在编程，自学编程成了我的爱好。I mean my earliest memories I thought I was going to be a scientist, but like you know as a three-year-old that means like lab coats and test tubes and I don't know what else, right? My dad uh very insightfully knew that computers would be important. Like that was not his field at all. He was kind of in carpentry and set design things like that. So, there was always a computer in the house. It was usually kind of a low-end thing of you know whatever we could scrape together and afford. Uh and then I remember I really got my start I think I was around 11 or 12 and instead of buying candy for everyone for Valentine's one year he went to the bookstore and I don't know what my brother got, but I got a book on learn QBasic. And it was all kind of downhill from there. Like I spent probably the next five, six years like programming, teaching myself to program was my hobby.

偶尔我会碰巧认识一些和我同龄、对这个稍微有点兴趣的孩子。后来我们搬到了拉斯维加斯，我上了一所设有计算机科学课程的重点高中。嗯，那所高中现在其实很有名。我当时完全不知道。对，我最开始基本上是自学的，那还是互联网出现之前，想学点东西得费很大劲。嗯，不过就是那本书让我走上了这条路。然后高中毕业后，你去大学学这个就很顺理成章了。Occasionally I would wind up like meeting, you know, other kids my age that were a little into it. We moved eventually to Las Vegas and I went to a magnet school that had a computer science program. Um that is actually a really well-regarded high school these days. I had no idea. And yeah, like just kind of self-taught initially uh pre-internet back when you had to really fight for it. Um but yeah, that set me on my path, that book. And then you after high school it was kind of obvious you went to college for it.

是的，呃，我去了哈维穆德学院，那是一所很棒的学校，兼顾技术教育和博雅教育。嗯，那种既教你制造武器、又教你不要使用武器的地方，差不多就是这样。后来我在那里认识了我妻子，呃，她比我低几个年级，所以我不想搬走。她当时还在上学，于是我就在加州大学河滨分校读了硕士，学的是计算机科学教育。Yeah. Uh so I went to Harvey Mudd uh which is a great school with a mix of, you know, tech and liberal arts education. Um the kind of place that'll teach you to build weapons and teach you to not to use them, that sort of thing. And then I met my wife uh there and she was a little bit more junior than I was, so I didn't want to move away. She was still in school, so I did my master's at UC Riverside actually in computer science education.

嗯。呃，好吧。我有过一段挺奇怪的经历，研究生阶段非常特别。是啊，我在 Riverside 待了四年，读计算机科学教育方向的博士，研究领域算是应用人工智能、教育数据挖掘和计算机科学教育。呃，我在一些最早期的计算机科学教育研究会议上发表过论文。我的导师是系主任。他通常不怎么带研究生，因为这个研究领域并不是他的重点，但他一直担任系主任。他是那种很有魅力、善于社交、也挺懂政治的人，知道各种来龙去脉。所以，我的研究生工作很大一部分就是了解我们一路走到今天的各种故事，以及在课程没人上的时候去教课……Mhm. Um All righty. I did a kind of weird I had a very strange graduate experience, yeah, I spent four years at Riverside doing a PhD in CS Ed, kind of applied AI, educational data mining, computer science education. Um So, some of the earliest conferences on CS Ed research, I published there. And my uh my advisor was the department chair. He never generally ran grad students, like the research area was not his focus, but he was constantly the chair. He was this like charming, you know, social, political sort of guy that knew all the stories. And so, my graduate work was a lot of learn all of the stories of how we got here and teach all of the classes uh whenever there was a hole in the

是的，我们可能会在整个过程中反复聊到这个教育与计算机科学的话题。我们之前聊过，所以我知道一些。不过，接下来聊聊你大学毕业之后的事吧。你当时在找工作。Yeah, and we'll we'll we'll keep coming back to probably this like this education computer science thing throughout this thing. So, it's a we've talked before, so I know. But, let's let's jump next like you now graduated from college. You were looking for a job.

是的。你后来发现了什么？呃，起初我做的是类似咨询公司的工作。又是双职涯难题。我妻子去了圣迭戈读研究生。我博士毕业后没能找到教授职位，所以就做了咨询工作。我当时在一家小型咨询初创公司，规模大约有30到50人。那段时间，我主要是通过间接的方式为 DirecTV 工作，做机顶盒的嵌入式系统相关工作。Yep. What did you find? Uh so, first I did a sort of consulting group. Again, two-body problem. My wife went to grad school in San Diego. I did not get a professorship after my PhD. So, I did this consulting stuff. I was at a small startup consulting group, about 30-50 people. Mostly, I worked for indirectly for DirecTV during the embedded system stuff on the set-top boxes.

嗯。然后，经历了四年之后，呃，我们读完了研究生，也结束了所有那些事。我接受了去 Google 面试的机会。呃，后来拿到了 offer。呃，我们决定不去湾区，于是他们把我们调到了纽约。所以，我们一直待在这里。Mhm. And then, after four years of that, uh we were done with grad schools, we were done with all of that. I took the offer to do Google interview. Uh got the offer. Uh decided not to go to the Bay Area. And they moved us to New York. So, we've been here ever since.

所以，那会儿谷歌正在纽约这里开设办公室。那间办公室已经开了，规模也相当大。那是2010年。我想当时那里有几千人。So, this is when the Google was opening an office here in New York. And that office was already open and reasonably big. This was 2010. So, I think there were a few thousand people there.

接着，到了2010年——谷歌成立于1998年，并于2004年上市。我记得，大约从2005年到2010年，谷歌开始真正积累起全球品牌影响力，人们会觉得：“哇，谷歌是个理想的工作之地。”所以，差不多就在你申请的时候，谷歌其实是最难进的公司之一。有点像今天的Anthropic、去年的OpenAI，或者你知道的，2010年代中期的Uber。And then and in 2010, so Google was founded in '98. They went public in 2004. I remember that they started to really accumulate a global brand as like, "Wow, Google is the place to work at around like 2005 to 2010. So, right around when you were applying, it was actually one of the hardest places to get into. A bit like today, Anthropic or last year OpenAI or the you know, like in the mid mid 2010s, Uber.

嗯。你觉得面试过程怎么样？后来拿到 offer 又是什么感觉？因为当时竞争肯定挺激烈的。确实很激烈。我有点惊讶他们居然给了我 offer。我没……我觉得自己表现得不怎么样。我记得当时也不知道是出于什么傻理由，我真的特别不想浪费一大堆宝贵的假期。所以我就在面试当天早上从圣迭戈飞了过去，而不是明智地……Yeah. How did you find the interview experience and getting an offer? Cuz it must have been pretty competitive at that point. It was competitive. I was a little surprised that they gave me the offer. I didn't I felt like I didn't do that great. I remember for some stupid reason, I really really didn't want to spend a bunch of like precious vacation days. So, I flew up from San Diego the morning of instead of sensibly like

然后他们就会把酒店和其他一切费用都付了。是啊。我只是不想……我也不知道。我这人容易焦虑，喜欢自己的习惯和作息之类的。为了一个重要面试早上五点起床，可不是个好主意，各位。嗯，给你们个小建议。嗯，当时有几件事。比如，我记得有一次面试题比较简单，像是钟表数学题之类的。严格来说，题目讲的是火星探测车的摄像头角度什么的。然后我当时想：“我累了，面试脑子也不太清醒，这就是基础数学。所以，我先写个输入输出都正确的函数；要是我今天早上没这么笨，这样就能行。”于是我就全都按这个思路做了。我觉得面试官其实挺喜欢我这种做法的，大概就是：“对，这部分不重要。咱们聊点别的吧。”所以，嗯。And then they would have paid for the hotel and everything. Yeah. I just didn't want to like I don't know. I'm an anxious person. I like my habits and routines and stuff. Getting up at 5:00 for a big interview is not a good plan, folks. Uh hot tip. Uh so, there were a couple things. Like, I remember one interview was like a relatively simple like clock math sort of thing. It was technically camera angles on a Mars rover or something. And there was a point in there was like, "I'm tired and having interview brain and this is just basic math. So, here's a function that has the right inputs and outputs and if I wasn't stupid this morning, that would work." And I just did it all in terms of that. And I think my interviewer actually really liked that approach of like, "Yeah, this is not the important part. Like, let's just talk." And so, yeah.

最后，他们给了我工作机会，然后，嗯，我搬去了纽约。你开始了。然后你加入了，你拿到了，你拿到了核帽子。嗯哼。对。没错。那是……Eventually, they gave me the offer and yeah, moved to New York. you started up. And then you joined you got you got the nuclear hat. Uh-huh. Yep. Absolutely. It was

那么，你加入 Google 时是做什么的？呃，简单来说，我当时在……而且，我觉得 Google 对新员工的安排未必是最合适的。And so, what did you work on at Google when when you joined? Uh so, briefly, I was on and like I don't think that Google had the best placement for new hires necessarily.

就像我们说的入职流程。那段经历有点不顺，因为正如我说的，我感兴趣的是开发者效率、解决问题之类的。我有网络方面的背景，也有 API 设计方面的背景，诸如此类。他们说：“哦，你懂网络，那就把你安排到这个团队吧，负责监控流量的大小，以及流量从哪里穿过 Google 网络的边界。”但实际上，这是一个数据库问题，只不过数据的主题是网络。我当时就想：“我对数据库一窍不通，那从来不是我的专长。”所以这并不是很合适。然后几乎就在那之后，差不多入职两个月时，Onboarding process as we say. That was a little rough cuz like I said, the things that I'm interested in are like developer efficiency, problem solves, like I have a background in networks, I have a background in like API design, those sorts of things. They said, "Oh, you know networks, uh so let's put you on this team that monitors the amount of traffic and where that is crossing the edge of the Google network." Uh which is actually a databases problem with networks as the topic of all of the data that you're doing. I'm like, "I don't know anything about databases. That was never my thing." So, it wasn't a great fit. Um and then almost immediately after that, like 2 months in,

我现在就想稍微反驳一下：得了吧。你都要加入 Google 了。你之前有……什么来着？你上过大学，也有四五年的工作经验。你加入一家公司，尤其是一家炙手可热的公司时，他们会说：“好，去做 X。”而你会说：“啊，我不太……”难道你不想说：“让我深入了解一下，看看这件事为什么对业务很重要”吗？我这是在反驳你啊。I want to push a little bit back here already is like, "Come on." Like you're you're joining Google. You had like what? Like you had college. You had Yeah. 4 or 5 years of experience. When like you join a company, especially like a hot company, they said like, "All right, do X." And you're like, "Ah, I'm not really." They're like, "Would you not want to say like let let me just go deep into this to see why the why it's important for the business?" I am I am pushing back on you here.

不，嗯。没事，请尽管说。随时都可以。我确实尽我所能向那个团队学习，你知道的，当然了。呃，那些事情里有些确实存在一点人际关系上的紧张。No, yeah. No, please do. Always. I did what I could to learn, you know, from that team, for sure. Uh there was a little like interpersonal tension in some of those things.

好吧，事情一开始就有点像这样。你心里隐隐有种不安的感觉。对，就像是觉得：“嗯，这事儿好像不太对劲。”后来发了一封邮件给纽约的所有工程师，说：“嘿，我们在考虑组建一个新团队，负责维护所有旧的 C++ 底层基础设施代码——这些代码是由员工编号只有两位数的老员工写的。他们有更重要的事情要做，不该还忙着处理这些组件的补丁请求。所以，我们希望有人能来维护它们。”呃，我和另外大概九、十个人举了手，但到了第二次会议，只有我一个人来了。呃，于是我就这么加入了那个团队。</final>Okay, so it already started a bit like that. You kind of had this nagging feeling. Yeah, like it was just like, "Yeah, this wasn't quite right." And then there was a like email that went out to all the engineers in New York saying like, "Hey, we're thinking about spinning up a new team that handles all of the old like C++ nuts and bolts infrastructure code that was written by people whose employee IDs are like two digits. They have more important things to do than to handle like patch requests for all of those, you know, components. So, we would like people to maintain that." Uh and me and I don't know, nine or 10 other people like raised their hands, and I was the only person that showed up to like the second meeting. Uh so, I just kind of got onto that team.

哦，我明白了。所以我觉得，背景信息其实很重要，因为你知道，大家听到“哦，我要加入这个团队了”时……我觉得一开始我不太喜欢的是，我认为缺少的背景信息、其中的区别，首先就是 Google 当时发展得非常快，新团队不断涌现。而且换团队也没什么问题，对吧？你会更倾向于这样想：好吧，你知道，这个团队不管是从他们做的事情来看，还是有时候从人与人是否合拍来看，可能都不是一个你会待很多年的地方。对。你已经尽力了，然后当你看到一个机会，知道它更符合自己的优势时，你就会想：那就试试吧。所以对你来说，就是 C++ 这类底层的东西。Oh I get it. So basically I think the context is just important cuz I think, you know, folks hearing, "Oh, I'm joining this team." Like I didn't really like the first thing I think the difference the context that was missing is like first of all, Google was growing really quickly. New teams were starting up left and right. And also like moving teams was kind of fine, right? And you were more looking for like, all right, like you knew that this team, both for the what they were doing and also sometimes there's not a great people fit, it would probably not be the one where you're going to be staying for many years. Yeah. You did the best you can, and then when you saw an opportunity, you knew it was better for your strengths, you're like, let's go for it. So for you, C++ low-level stuff.

对，我是说，当年我在 DirecTV 做咨询时，做过一些事情，比如构建一个 API 来实现 UPnP，也就是通用即插即用之类的功能，还有局域网 RPC 之类的东西。Yeah, I mean, back when I had been doing the consulting at DirecTV, there was stuff like build an API to do UPnP, like universal plug and play stuff, like local network RPC sorts of stuff.

嗯，远程过程调用？是啊，没错。所以当时有很多人、很多团队都在手动拼装每个请求的 XML 结构，只为了实现一次客户端调用之类的。大家，我们明明可以做得更好。我在组装整个 API 时，可能确实有点过于耍聪明了，但就是……对，这正是我喜欢的地方。Um remote procedure call? Yeah, right. And so it had been a lot of people teams were manually assembling like the XML structure for every request to like implement a single client call or something like that. It was like, we could do better, folks. And like I was probably a little too clever in the way that I assembled all of that API, but it was like it Yeah, like that was the thing that I liked.

这个团队更像是自下而上的倡议吗？比如说，嘿，Google 到处都有一些 C++ 项目，我们不如聚在一起，最开始先利用业余时间，看看能不能做点什么？还是说更像是某个经理之类的人提出：“我确实在考虑组建一个全职团队来做这件事”？This team, what was it more of initiative of like, hey, Google has a bunch of C++ here and there, kind of like roots up, like, you know, let's get together and initially in our free time, let's see if we can do something, or was it more some manager type said like, I'm actually thinking of assembling a team, a full-time team on this?

所以我觉得，那应该是谷歌开始真正严格规定你要归属某个特定团队、而且团队编制有限之前的最后一年左右。那时候有点混乱，相关安排也比较随意。我其实也可能记错了，因为当时我还算是个新人，对编制是怎么运作的内部情况可能还不太了解。不过，嗯，我很快就转了过去，天哪，那地方简直太适合我了。So this was I think like the last year before Google would got actually pretty formal about your embedded to a particular team and head count is limited. It's a little chaotic, it's a little loosey-goosey about how those things work. I could actually be wrong about that cuz I was still, you know, new enough that the internals of how head count works might have been just not clear. But yeah, like moved over pretty quick, and boy, that was exactly the place for me.

好吧，那跟我说说吧。为什么？为什么那里会是那个地方？我们能想象这类工作是什么样的？我的意思是，因为听你描述，像是接手 Google 上别人写的各种乱七八糟的 C++ 代码，这对我来说简直就是地狱。你知道，作为一名工程师，尤其是对 pre-add 来说，对吧？比如弄明白另一个工程师以前写的东西——那个人可能已经离职了，而某个团队一直在用这段代码，而且用得好好的。听起来这简直是两头不讨好：你接手后做了修改，结果把某些东西弄坏了，人家就会怪你；可如果你接手后做得特别好，他们可能压根都不会注意到，因为它本来就一直运行正常，现在也还是好好的。All right, then tell me about it. Why Why was it the place? What kind of work can we imagine of like I mean, cuz it sounds like when you describe to me like taking random C++ stuff that people wrote at Google, like that sounds like the version of hell for me, like, you know, like as an engineer, especially to pre-add, right? Like understanding what another engineer at some point wrote who might have left and a team is using it and it's working for them like that it sounds like it's a lose-lose because if you take it over and you make a change and you break someone they'll be mad at you and uh if you do it and you do a great job they'll probably not even think about it cuz it just it's always worked it still works great.

测试、可持续变更与工程反馈Testing, sustainable change, and engineering feedback

呃，幸运的是，在这件事发生前几年，大家对做出改动的顾虑，以及相应的安全网，就已经建立得相当完善了。具体来说——这也会涉及我们待会儿肯定会聊到的话题——Google 早就经历过那个阶段：没错，你必须写测试。对吧？Uh luckily the fear and the safety net for making changes had been pretty well established a couple years before this played out. Specifically and like this goes to topics that we'll get to in a second I'm sure. Specifically like Google already went through the phase of yes you have to write tests. Right?

2010 年时，这在业内还不是件显而易见的事。对。不过我觉得，故事大概是这样的：2006、2007 年左右，搜索团队失去了按固定节奏发布版本的能力。也就是说，我们当时想做到每月发布一次，但他们可能只能每季度发布一次，因为……In 2010 this was not an obvious thing in the industry. Right. But like I think the story is 2006 2007 uh search lost the ability to push a release on a regular cadence. Like it was down to like we were trying for monthly and they were maybe only get once a quarter because

哦，所以这就是谷歌如此痴迷于测试、质量之类的原因。嗯哼。所以他们的核心盈利产品直到2006年都像是戴着手铐，没法随意推动改动。哇。Oh so this is why is Google obsession with tests and quality and all that. Uh-huh. So the core money making product was kind of handcuffed not being able to push around through 2006. Wow.

大约在2006年，你做的几乎任何事情都会牵涉到前端、搜索之类的东西。整个架构、各部分的隔离，以及多应用、多产品的体系都还不完善。所以，如果你在改 Gmail，仍然有可能同时也在改搜索。And circa 2006 almost anything that you did had some tendrils in like the front end or search or stuff like that the whole architecture and separation and like multi-app multi-product like world that was still not right. So if you're making changes to Gmail there were still chances that you were like making changes to search.

哇。所以当时整个进度都被拖住了。于是发布工程师们团结起来，直接表态：如果没有测试，就不许合并这项改动。就这么定了。我们不在乎副总裁说什么，也不在乎这个功能有多重要。你们就是不能这么做。不然我们就会回滚它。Wow. And so like everything was you know held up. So the release engineers like they banded together and they simply just said like you will not merge this change if there is not tests. Period. We do not care what VP says anything. We do not care how important this feature is. You will not do that. Like we will roll that back.

没错。而且你一旦划清界限，就连那些觉得自己特别聪明的人也会说：“你怎么敢让我写测试？这简直有失我的身份。”Yep. And like as soon as you put a line in the sand even the people that are like I'm very smart how dare you ask me to write tests. Like this is beneath me.

然后，基本上无论是接手或承担维护工作，还是修改任何一个 C++ 库，你都有测试作为保障，因此可以很有信心地重构这些东西，而且所有测试都会通过。是的，要么它能正常工作，要么就是测试覆盖率本来就不够。And then so basically taking over or taking on maintenance or or even changing any a library C++ library, you had the test so you could have high confidence if you refactor these things all the test pass. Yeah, either it works or there was never enough test coverage.

对，没错。对吧？而且，只要有一天算是赢了就行，因为如果你……如果你能暴露出测试覆盖不足的问题，那反而更好。好吧，今天可能会崩溃，但明天，或者一年后，流量反正都会翻倍。Right, exactly. Right? And like And any day where it's a win because if you it's it's better if you expose the lack of test coverage and okay, you have a crash today, but tomorrow or a year from now you'll have twice as much traffic anyway.

对，没错。还有，我深信的一点是，如果你因为害怕而不敢修改某样东西，那就必须着手解决这个问题。恐惧不是工程实践可以接受的依据。我想这话在书的前两三页里就提到了——我这么说已经有十年了：如果遇到任何有价值的改动，你都能安全地完成它，那么你的代码库就是可持续的，对吧？你可以选择不做这个改动，对吧？这可能是技术债务，也可能是产品优先级不同，或者其他原因。但如果你无力应对变化，那你就是在押下重注，或者说冒着很大的风险，赌这个变化并不关键或不重要。我不想泼大家冷水，但过去几年，安全领域的情况确实变得非常、非常糟糕。Right, exactly. And like uh it's one of the things that I believe very deeply is if you are held back from making changes to a thing out of fear, you have to go in and fix that. Like fear is not an acceptable basis for engineering. And I think it's in the first two or three pages of the book uh I've said now for 10 years you know, your code base is sustainable if for any valuable change that comes along, you are capable of making that change safely, right? You may choose not to make that change, right? That could be technical debt or, you know, different product priorities or whatever. But if you're incapable of reacting to change, then you're placing a high bet or high risk bet that the change isn't critical or isn't important. And I hate to break it to people, but like security world has gotten real real bad in the last few years.

就好像没有什么是不会改变的。能够改变本身带来的战略优势，简直不可思议。能不能这样说：如果我加入一家公司，不管是初创公司还是大公司，加入团队后查看代码库，在最初几周、几个月里，我因为担心改动会出问题、把生产环境弄崩，而不敢提交代码；这说明我正在维护一个工程质量很差的系统。Like there is nothing that is not going to change. Like the strategic advantage of being able to change is incredible. Is it safe to say that if I join a company, a startup, a large company, whatever company I join the team and I look at the code base and you know, my first weeks, my first months I'm just being afraid of pushing code changes cuz I worry this thing will break. I'll break production. That I'm working on a system that is just, let's say it's poorly engineered.

可能是系统设计得不好，也可能是你的问题——那里的入职培训和指导工作没有做到位，对吧？所以问题无非出在其中一方。It could be the system is poorly engineered or it could be you there's some onboarding and mentoring that didn't happen there. Right? So one or the other problem.

肯定是其中一个。而且我觉得，这也涉及一些教育方面的东西，比如我们在本科阶段接受的教育，以及我们对这份工作是什么样子的描述：总有一个正确答案，有对有错，不只是权衡取舍。每当有人审视你做的事情时，你都会被打分。One or the other for sure. And I think and this goes to some of the educational stuff, like we in undergrad, you know, education and like the way that we kind of portray what the job is like, there is a correct answer. There is right and wrong. It is not just the trade-offs. And you're graded anytime someone looks at what you have done.

嗯，对吧？我觉得这对刚毕业的人来说尤其难。他们很容易陷入一种担忧：我不知道自己做得对不对，也不知道这是不是你想要的答案，因为他们被误导，以为一定有一个正确答案。但其实这只是权衡取舍，对吧？它只是设计空间中的某个选择。Mhm. Right? And I think it's going to be for especially for new grads, it's really hard. It's really easy to get into a fear of like, I don't know if I did this right. I don't know if this was the answer you were looking for because they've been falsely given this perspective that there's a right answer instead of course it's just a trade-off, right? It's at some point in the design space.

我想你也在说，这些应届毕业生也习惯了这样的模式：你做了一件有意义的事，通常是一门课或者一场考试，然后就会得到反馈。你会得到一个分数、一个等级，至少也会得到一个赞、通过或不通过。我知道我应该记得，我刚去第一份工作的时候就该记得这一点。这真的很奇怪。比如，加入公司后，我做了这个项目，然后什么反馈也没有。接着我又做了另一件事，还是没有反馈。后来我和公司 CEO 进行了一对一谈话，我还以为他们要开除我，因为显然，我知道自己有时候会在大白天偷懒，因为我把手头的事做完了。现在回想起来，我当时效率挺高的，只不过我做完了手头的事，然后就上网闲逛。And I guess you're also saying that these new grads they're also used to you do something that is a meaningful effort, typically a class or an exam, and you get feedback. You get a scale, you get a grade, you get a thumbs up, a pass or a fail at the very least. And I know I should remember when when I went to my first workplace, I should remember this. This is really weird. Like, join the company, I did I built this project, and then nothing. And then I, you know, I do another thing and then nothing. And then I have a I have a one-on-one with the CEO of the company, and I'm thinking they're going to fire me cuz like clearly like I knew that I don't know like middle of the day like I was sometimes slacking off cuz I finished my stuff. In hindsight, I was pretty efficient, but I just finished my stuff and then I was just browsing the internet.

我告诉他们：“我准备好了。”我当时还挺确定自己可能会被训斥什么的。结果他们却跟我说：“哦，干得太棒了。你上手这么快，我们真的很满意。”而我当时……但不同之处在于，在那之前，我已经有好几年一直在接受直接反馈了，可我脑子里就是没把这两件事联系起来。I told them, "I'm ready." And I was pretty sure like maybe I'll be reprimanded or something. And instead, told me like, "Oh, amazing job. Like, you've onboarded so quickly. We're so happy with you." And I was But the difference was that up until then I had years of getting direct feedback, and it didn't connect in my mind.

是啊。另一方面就是，如果你是本科生，唯一会看你代码的人，就是为了给你打分、评判你，对吧？而当你成为一名更有经验的工程师之后呢？你会经常征求反馈，但那只是例行确认一下：我们方向对吗？你觉得这样说得通吗？对吧？你能得到的非评判式反馈越多，效率就会越高。比如说：“唉，我真不喜欢我们给所有新毕业生和初级工程师灌输了完全错误的本能。”那么，回到 Google 这个话题，abseil 是什么？它的正确发音是什么？Yeah. The other part of that is like the only time that a human is going to look at your code if you're an undergrad is to grade you, is to judge you. Right? Whereas when you like become a more experienced engineer, right? Like, you're asking for feedback regularly, but it's just like a check-in like, are we going in the right direction? Does this make sense to you, right? And the more of that feedback that you can get that isn't judgment, the more effective you will be. Like, "Oh, I hate that we've like given all of the new grads and all the junior engineers exactly the wrong instinct." So, go going back to Google, what is abseil? How do you pronounce it correctly?

Abseil。Abseil。是的。Abseil. Abseil. Yeah.

Abseil 与如何安全地重构数百万行代码Abseil and refactoring millions of lines safely

所以，Abseil 大约是 10 年前开始的，就在最初转向云计算之后不久。当时有人提出：“嘿，除了这些了不起的生产系统，我们还有这么多出色的开发者工具。也许我们也应该尝试把这些开发者工具对外开放。”与此同时，Google 也在逐步转型为 Alphabet。因此，在开发者工具方面，一层问题是：我们该如何在 Alphabet 旗下的不同公司之间共享开发者工具？又该如何共享高价值的内部接口和 API，以及各种技术组件？当它们不再属于同一个企业、同一家公司时，我们该如何共享这些东西？So, abseil was starting about 10 years ago, shortly after the initial pivot to cloud, there was a motion to "Hey, we have all of these amazing developer tools in addition to the all this amazing production stuff. Maybe we should try to externalize the developer tools as well. And at the same time, there was also a little bit of Google shifting into Alphabet. So, for both the developer tooling aspects at one level of like, how do we share developer tools amongst different companies within the Alphabet umbrella? And how do we share high-value, like, internal interfaces and APIs and, you know, tech components? How do we share those when it's not one, you know, single corporate one single company?

而且也不再是一个单体仓库了，对吧？是的，越来越不是了。没错。嗯，所以有一大堆常规工作，比如，怎么让这些开发者工具支持多租户，并且不那么完全依赖那个生态系统。And also not one mono repo, right? Increasingly, yeah. Exactly. Um and so, there's a bunch of work that's kind of the normal, like, okay, what does it take to make these developer tools like multi-tenant and like, you know, slightly less completely tied into that ecosystem.

另外，针对那些不太熟悉多租户的人来说，Google 内部的多租户是什么意思？嗯，这原本是指 Alphabet 旗下其他公司的多租户，然后可能会进一步扩展到云客户。And just multi-tenant for those who are who are not that familiar with What does multi-tenant mean inside of Google? Uh well, so this would have been multi-tenant of other companies within the Alphabet umbrella, and then maybe extend that out to cloud customers.

哦哦，明白了。对，就是说，规模大得多一些，谷歌理论上也能用它，差不多是这个意思。这后来并没有成为最热门的话题，一两年后，他们也就放弃了这个想法。嗯，不过说到那些底层组件，比如说，如果你想把这些在内部单一代码仓库里编写的东西分享出去，怎样才能有效地做到这一点？Abseil 基本上就是这么一层通用的 C++ 惯用写法。也就是说，这是谷歌所有东西所采用的共同语言。我们把它开源吧，这样谷歌所有技术就都有了一个共同的基础。与此同时，大家也在问：这些共同语言里有些东西很糟糕，也算是技术债；我们是不是应该先把它们整理好，再决定永远沿用？值得称赞的是，他们的答案是肯定的。所以，Abseil 开源项目就是那些经过整理的内容在公开环境中的呈现。我会非常有力地为此辩护：大部分工作都是在做这件事。Oh oh, got it. Yeah, so like a like a way more and the Google could theoretically use it, something like that. That became not the hottest topic and they kind of dropped that idea after a year or two. Um but, the low-level components, like, if you wanted to share these things that were written internally in the mono repo, what would it take to do that effectively? And abseil was basically here is the layer of common like C++ idiom. Like this is the vernacular that everything at Google is written out of. Let's open source that so that there's a common substrate for all like Google tech. At the same time, the question was some of this vernacular is gross and tech teddy should we clean that up before we commit to it forever? And the answer was yes to their great credit. So, the Abseil open source project is the public like projection of the stuff that got cleaned up. Most of the work was that was I that would defend pretty strongly.

那可能是人类历史上规模最大的重构任务了。不会吧。是啊，当时大概有十、十个或者十二个人全职投入，使用着目前还没人能理解的世界级工具，只是为了清理代码，并确保外部符合惯用写法的代码能与内部符合惯用写法的代码兼容。That was probably the largest refactoring task in human history. No way. Yeah, we had like 10 10 or 12 people working full-time with world-class tools that no one else understands yet just cleaning up and making sure that idiomatic code externally would be compatible with idiomatic code internally.

显然，当你谈论清理工作时，你说的是清理一些实用工具和组件，而它们位于全球使用量最高的一些服务的核心位置，比如 Google 搜索。And obviously when you're talking about cleaning up you're talking about cleaning up utilities and components that are in the middle of some of the highest use services in the world, Google search

没错。Gmail，没错。地图也是，凡是你能想到的，全都有。全都如此。就像，如果如果如果你弄坏了什么东西，你可能迟早会看到这些服务中的某一个发生故障。Yep. Gmail Yep. Maps, you name it. All of it. Like if if if you would break something, you would probably see at some point an outage in one of those services.

我记得当时大概有 2 亿到 2.5 亿行 C++ 代码，其中自有的 C++ 代码就有 2.5 亿行，还不包括外部依赖。呃，我想这就是当时 Google 公布的数字。那时候大概有 1 万名工程师，每个月都在修改那个代码库。所以，我们的工作——我们开玩笑说，这可是个纽约梗——我们的工作在逻辑上相当于：Google 有了一项用于摩天大楼地基的新技术，而我们要给帝国大厦更换地基。我们不能关闭大楼，也不能封堵交通。结果还发现地下室里有核废料。没事，伙计们，我们能搞定。就是……这支团队简直不可思议。真是一支很棒的团队。It was at the time, I think it was 200 or 250 million lines of C++ code with 250 million lines of C++ first party, not counting external dependencies. Uh and Google had that kind of I think that was the public number at the time. 10,000 engineers probably at the time uh making edits to that code base in a month. And so, our job was we joked about That's a New York reference. We joked about it as our job is the logical equivalent of Google has a new technology for the skyscraper foundations. We're replacing the foundation under the Empire State Building. We're not allowed to close the building or block traffic. And we discovered nuclear waste in the basement. It's okay, guys. We got this. Like, it was It was a magically It was a great team.

我只是想让大家对 2.5 亿行代码有个直观的概念，因为如今有了 AI，AI 可以生成……你知道，我们现在能做到的数字很惊人。它一小时就能生成几万行代码，等等。如果你愿意，甚至可以达到几百万行。说实话，一个智能体就能做到。不过在 AI 出现之前，Uber 的移动应用在 iOS 和 Android 上分别大约有 100 万行代码，而且每个平台的代码都是由 200 名工程师耗时数年编写的。Anthropic 的 Bun 运行时最近重写了大约——我想是 50 万或 90 万行代码，而那是一个小团队完成的。我很少能找到超过 AI 出现前规模的项目，也就是比如说超过 300 万行代码的项目；而这类项目通常要由数百名工程师花好几年时间编写。I just want to put the 250 million lines of code in perspective cuz today with AI AI can generate like, you know, like we have crazy numbers. It can generate tens of thousands of lines of code in an hour, etc. And you can get to millions if if you want to. Honestly, just an agent can do it. However, pre-AI uh Uber's uh mobile application was about a million lines of code on iOS and on Android, and that was each written by 200 engineers for years. Bun uh runtime at Anthropic just rewrote something like I think it was like 500 or 900,000 lines of code, and that was written by a small team. I find it rare to find examples of a project that has more than pre-AI, more than let's say 3 million lines of code, and that will typically be hundreds of engineers writing it for several years.

所以，在这个、在这个……我当时想的是2.5亿，这大约是我听说过的代码库规模的100倍。我们说的显然是为生产环境编写的东西。你不是在这儿随便玩玩、到处塞点脚手架代码，对吧？而且你说“第一方”时，接手一个开源组件确实很容易让代码量变得非常大，但不是这样。So, in this in this The reason I was like 250 million, that is about 100 times more than I've heard for codebase. And we're talking about like clearly this is written for production. You're not like just goofing around and pushing some scaffolding here and there and right. And when you say first party, it's easy to have a lot lot of code when you take on an open-source component, but no.

不，不，那些全都是 Google 员工编写的。然后，呃，我们对事情的发展有一些了解。好，所以在人类历史上的那个时刻，最大的重构历史可能……呃，你大概不是在删节吧。No. No, that was all Googler authored. And uh so, we have some insight into uh how things go. Okay, so the largest refactoring history at that point in uh human history might have uh you're not expurgating likely.

我的意思是，我没法证明，但我会觉得很意外。所以，怎么说呢，好吧，当你身处一个10到12人的团队中，面对这样一项极其庞大、看起来几乎……的任务时，你会怎么着手？你会怎么说，比如……怎么把它拆解？怎么规划？又怎么加快进度？因为显然，如果只是手工完成，这件事肯定没法完全行得通。I mean, I can't prove it, but I would be surprised. So, how Okay, when you have this You're in the middle of this 10 to 12 people. You have this massive massive task that seems giant and almost How do you go about it? How do you say like How do you break it down? How do you plan for it? How do you speed it up because you clearly if you just did it by hand, this would have not fully worked.

对。所以，促成这一切的因素之一，也源于我一开始在那个底层 C++ 基础设施团队工作。我们想：好，如果我们负责那些接口——也就是 Google 里几乎所有东西赖以构建的基础组件，位于数据库层之下很远的地方，比如缓存、容器、字符串操作例程、命令行标志之类的——那也许把它们做得更好是有价值的。但如果有五万个调用点，或者需要改动十万处才能更改那个 API，该怎么做呢？幸运的是，我和编译器团队的人既是朋友，后来在组织架构上也算是近亲，尤其是 Clang/LLVM 团队的人。于是他们开始着手做 AST 转换之类的事情。Right. So, uh one of the things that had enabled any of this and that came out of having been on that the low-level C++ infrastructure team to start with was Okay, if we own the interfaces that are kind of the nuts and bolts that everything at Google is written out of like way below the database level just like caches, containers, string manipulation routines, command line flags, like that sort of thing. If we own those things, maybe it's valuable to make them better. But how do you do that when there's 50,000 call sites or 100,000 edits that need to be made to change that API? And so luckily I was friends and org chart cousins eventually with the compiler team, especially clang LLVM people. And so they started doing stuff in the AST transformation sort of thing.

AST？哦，抽象语法树。也就是说，你先拿到解析树。你知道，这有点像 Google 的 MapReduce。所以，如果你对整个代码库做一次 MapReduce，映射器会解析所有 C++ 编译单元，也就是所有构建目标，并生成解析树。然后你就可以针对特定情况匹配解析树——这不是文本匹配，而是我能保证你在特定上下文中调用了这个特定函数——接着就可以应用一些代码，根据匹配结果重写代码。这样一来，我们就能借助编译器辅助，半自动地重构代码，并生成所有文本修改。后来发现，起初有一件事特别难：我们能生成修改内容，却没法把空白字符放到正确的位置。AST? Uh abstract syntax tree. So like you take the parse tree. And you know, it's Google like map reduce. So if you do a map reduce over the code base uh where the mapper parses all of the translation units of your C++ like all of the build targets and produces here is the parse tree, then you can match the parse tree for specific like it's not text match, it's I guarantee you are calling this particular function in this particular context and then you can apply some code to rewrite based on that. And so we had compiler assisted, you know, semi-automated refactoring to generate all of the text edits. Turns out one of the things that was really hard at first was we could generate the edit but we couldn't get the white space in the right places.

不可能吧。对，真的。所以 clang-format 的出现，是因为我当时希望有这么个工具。呃，它现在算是很多 C++ 之类语言的自动格式化工具了。但当时我根本没法完成这次重构，除非有人想出办法，给 C++ 搞一个自动调整空白字符的工具。于是你就这么做了，生成一个很大的改动。它太大了，没法放进代码库里，因为对于任何一个代码库来说，变更都有一个自然的日常规模。要是你试图编辑一万、两万个文件，很可能你还没来得及测试并重新同步，代码就已经发生偏差了。No way. Yeah, seriously. So clang-format exists because I wished for it. Uh this is like the auto formatter for many like C++ sorts of languages at this point. But it's like I literally cannot accomplish this refactoring until someone figures out a way to like hack together a auto white space for C++. And so you do that, you generate one you know, big edit. It is too large to fit in the code base um because for any given code base there's kind of a natural background level of how much change is happening. And if you're trying to edit 10,000 files, 20,000 files, it is likely the case that you will never be able to test and resync before something has gone out of sync.

是啊，对吧？有人改了点东西。没错。合并冲突，比如并行修改之类的。没错。你知道，在一家一万多人规模的公司里，你肯定不想说：“大家先别碰代码仓库，一个小时。让我把这事弄完。”这根本无法扩展，对吧？所以，技术上的做法是，你要拆解这些改动——想办法进行重构，让旧 API 和新 API 能以不同写法共存。Yeah. Right? Someone else edited something. Yeah, exactly. Merge conflicts, like parallel changes, that kind of stuff. Yeah, exactly. You know, you do not want at a, you know, 10,000-plus person company to be like, "Everyone stop touching the repo for an hour. Let me do this thing." Like that's not going to scale, right? And so the tech is you break all of like you figure out how to do your refactoring so that the old API and the new one can coexist in spelling.

对。然后你们并行处理，比如按目录结构拆分。像是：“好，我把这一批更新发给你，再把那一批更新发给你。”最后就会变成这样。等一切都整理干净了，接下来就得赶紧确保没人再复制粘贴旧的东西。呃，然后你删掉旧的，让新的成为默认版本，接着继续生活。就这样重复几百次，你的代码库就会好很多。Yeah. And then you parallelize, like just cut by like directory structure. Like, "All right, I'll send you this batch of updates, this batch of updates." So you wind up, you know, going like that. And then once everything is clean, then there's a race to make sure no one copy and pastes the old thing. Uh and then you delete the old thing, the new thing is the default, you move on with life. You just do that a few hundred times and your code base is in much better shape.

是啊，哇。然后你就一直一直一直在做这个，而与此同时，其他工程师呢，他们只是在做自己的事，用着这些东西，他们甚至都不知道这些东西，也不想了解你。我的意思是……Yeah, wow. And then you're you're doing this all all all the while while other engineers, they're just doing their thing, they're using these things they don't even know about, they don't want to know about you. I mean

没错。他们可能知道你的存在，但他们不应该改变他们的……就像你说的，放慢速度，或者……对。不过后来我们确实收到了一些关于其中部分内容的很棒反馈。比如……Exactly. They might be aware of you, but they shouldn't have to change their just as you said, slow down or Yep. But then we did get amazing feedback on some of this. Like

一开始大家会说：“你在干什么？怎么——为什么要改我的代码？这……我可不接受。”但很快他们就会说：“哦，这太棒了。”就像我离开一会儿，代码就变得更好了。而且我也不用担心去查“这样做对不对？”因为如果这样做不对，你早就把它删掉了。就像有人在那儿把代码库收拾得井井有条时，复制粘贴就成了“这事该怎么做？”的正确答案。找个别人已经做过的例子，复制过来，继续过日子，而且你有证据表明这大概是个合理的做法。因为要是错了，我们早就修好了。at first people are like, "What are you doing? How Why are you changing my code? This like I'm not okay with this." And very quickly they're like, "Oh, this is great." Like I go away, my code just gets better. Like and I don't need to worry about looking up like, "Is this the right way to do a thing?" Because if it was the wrong way to do a thing, you would have gotten rid of it already. Like when you have someone that is going through and just janitoring the code base like that, copy and paste becomes the correct answer for how do I do this? Like find someone else that did it once, you copy it, you move on with life, and you have evidence that it's probably a reasonable answer. Cuz if it was wrong, we would have fixed it already.

这很有意思，因为显然在今天，如果你要做一次大规模重构，大家首先想到的工具就是 AI。我们已经看到很多公司借助 AI 取得了巨大成功，因为 AI 有能力……你们面临的挑战是，代码库规模极其庞大。手动重写根本不可行。但在 Google，你们想出了一个非常巧妙的半自动化方案，它基于相当硬核的语言解析技术，并探索出新的方法，让你们能够以形式化的方式——甚至可能是完全形式化的方式——或者至少证明这件事是正确的。大多数团队既没有足够的资源，甚至也没有相应的专业知识来做到这一点。而现在，每个人都有专业能力去做的事情就是：“哦，AI，去做这个，再写测试，诸如此类。”It's very interesting because today, obviously, if you did a big refactoring, the obvious tool that you would reach for is AI as we've seen with so many companies having lots of success with Well, in the sense that AI is capable of The challenge that you had is you had this massive massive code base. Rewriting it by hand would have not been feasible, but at Google you came up with a very clever semi-automated approach, which was based on pretty hardcore uh language parsing and coming up with new ways where you could formally, maybe even formally or or at least prove that this thing will be correct, which is what most teams would not have the available capacity, even expertise to do. What everyone has the expert the capability to do right now is like, "Oh, AI, go and do this and do test and all this."

不过，我想实现的那种用 AI 重写的效果，感觉还是比你做的粗糙得多；你做的确定性强得多。However, where I wanted to get to like rewriting with AI feels still feels so much more janky than what you did, which was so much more deterministic.

是的。我在想，你在谷歌用的这种技术，之后会不会逐渐普及？还是说人们就会接受这种人工智能——你知道，它可能有用，也可能没用。Yes. And I wonder if this technique that you used at Google might at some point spread or or people will just put up with like AI kind of, you know, like it might or might not work.

我觉得，如果你正在找这样的工具，它其实已经存在了。嗯，尤其是在 Java 领域，像 OpenRewrite 这样的工具，你基本上只需要为每次运行做一点配置，然后说明：“这是我想在 Java 代码中查找的模式。这是改写后的样子。”接着它就会遍历你所有的 Java 源文件，快速完成更新。事实证明，AI 工具非常擅长生成 OpenRewrite 配方，这样消耗的 token 少得多，也准确得多、快得多，而且还能审计，对吧？这是一种好得多的模式。我记得我们听过一些来自 Netflix 和 Uber 的演讲——具体是不是这两家公司我不太确定——他们似乎都得出了相同的结论：你需要的是一种确定性工具，用来声明改写的意图。I think if you're looking for it's already out there. Um in the Java space in particular, uh tools like OpenRewrite, like you basically uh it's a little configuration per run for it and you say like, "This is the pattern I'm looking for in the Java code. This is how the rewrite would look." And uh it goes through and, you know, blasts through all your Java source files and does that update. Turns out AI tools are really, really good at generating OpenRewrite recipes, which is way cheaper on token consumption, and way more accurate, and much faster, and like auditable. Right? It is a substantially better pattern and I we've seen uh talks from I want to say Netflix and Uber, I could be wrong, um specifically on like everyone seems to be coming to the same conclusion of what you need is a deterministic tool that declares the intent of the rewrite.

你可以让 AI 编写一个小技能，教 AI 如何为那些工具创建配置，然后就可以继续过自己的生活了。其实在 C++ 领域，我有几位好朋友现在创办了一家初创公司，叫 Brontosaurus。它专门致力于这种声明式重写模式，能够以非常高层次的意图来表达，对 C++ 来说非常强大。You can have the AI like write a little skill to tell train the AI how to create the config for those tools and then you move on with life. In the C++ space actually, some good friends of mine have a startup right now. Uh it's called Brontosaurus uh that is specifically just about that sort of declarative rewrite pattern uh at a very high level of intent, very powerful for C++.

是啊，我喜欢用 AI 来帮助生成确定性软件工具转换的想法。对。呃，Kelsey Hightower 最近做了一场很棒的演讲，谈的是零 token 架构之类的东西。他的核心论点是——我觉得大家也都得出了同样的结论——不要让 AI 不断进行推理。应该用 AI 来生成真正负责干活的确定性工具，然后让 AI 来填补问题中你无法解决的部分，或者判断该在什么地方调用工具，诸如此类。但如果你的整个架构一直都在消耗 token，那也许有一种更便宜、更有效的方式来做……Yeah, I like the idea of using AI to help generate deterministic software tools transformations. Yeah. Uh Kelsey Hightower gave a great talk recently on like zero token architecture. And like his whole thesis, and I think everyone is coming to the same conclusion, don't use AI for constant inference. Use AI to generate the deterministic tool that will actually do the work and then have AI fill in the gaps on the pro- parts of the problem that you can't solve or where to invoke the tool, things like that. But like if your whole architecture is token consumption for all time, it's probably a cheaper and more effective way to do

是的，我最近刚听一位工程负责人说，他们在使用这些 AI 代码审查工具，效果挺不错，但价格非常昂贵，而且速度很慢。Yeah, I just recently heard a head of engineering tell me that they're using these AI code review tools which which are pretty good but very expensive and slow.

对。而且这个人说，等一下，如果我们告诉 AI，偶尔做一次全面的代码审查，那它发现问题时，就让它生成一条 lint 规则。Right. And this person said like hang on like what if we told the AI, okay like let's do a thorough code review every now and then but when it finds something let's have it generate a lint rule.

好的，请吧。那种方式既便宜又可重复，而且不再需要花30分钟，成本也更低；而且它本身就是非确定性的，下次可能找到，也可能找不到。这让人很沮丧。比如这个人就说：“听着，我们知道有些东西是确定的。”所以现在他们会时不时地继续做一些这样的审查。当然，一旦发现问题，他们就会启动推理 AI，让几个智能体一起工作，然后说：“好吧，你们能不能改进我们的确定性 lint 检查，帮帮它？”其实这个想法的灵感来自一个人听说了 Uber 的情况。我记得那应该是我在 Uber 工作时，我跟人讲过，入职的第一周，我几乎连代码都提交不了。那太痛苦了，因为 linter 一直拒绝我的代码，因为 Uber 有一种这样的工程文化——Yes, please. That which is cheap and repeatable and it will no longer take 30 minutes that the cost and also it's it's just non-deterministic. It might or might not find it next time. That was a frustrating. Like this person was like look when we know we have certain things. So now what they're doing is every now and then they still run some of these reviews and of course but whenever they find any issues then they fire up uh inference AI several agents and say all right, can you come up with an improvement in our deterministic linting and help it. And the inspiration came actually from this person heard about how Uber actually I think it was uh heard heard me talk about when I joined Uber, I could barely commit my code the first the first week. It was so painful cuz the linter just kept rejecting it because Uber had this uh engineering culture that

没错。在 AI 出现之前，每当你看到有什么东西出错，就会加一条 lint 规则。架构规则全都写在 lint 规则里。你没法做那种事，比如我们有自己的架构，你不能用错误的方式继承，因为 linter 会说：“呃，不行，你不能……你不能让 builder 继承自……我也不知道，composer 还是什么东西。”Yep. pre-AI, whenever you saw something break, you just put a lint rule. Architectural rules were all in lint rules. You could not have something like we had our architecture and you could not inherit the wrong way cuz the linter would say like uh-uh, you cannot you cannot inherit from like a builder cannot inherit from a I don't know what a composer or whatever that was.

是的。不，我觉得这完全说得通。比如说，我们尽量只吸取一次惨痛教训，把这些规则明确地写下来，放在某个确定可靠的地方，然后一视同仁、恰当地、公平地应用它们；同时把代码审查中真正有意思的部分留给人来做——确保我们关注的只是那些确实需要人来处理的事情，对吧？当时确实是这样。我觉得那时候并不是每个人都如此重视 lint 和静态分析，他们本该这么做。而现在也同样如此，对吧？我们不可能审查所有东西，但有些地方确实值得投入人力去关注。Yeah. No, I think it makes perfect sense. Like let's try to learn our hard lessons only once, codify those rules somewhere deterministic, apply them equally and appropriately and fairly like and leave the interesting parts of code review like make sure that the parts of code review that we're focusing on are only the things that humans need to be doing. Right? Which was true then. I don't think everyone invested in linting and static analysis that quite to that extent. They should have. And then it's equally true now. Right? Like we can't review everything but like there are places that require like this human attention is well spent.

赞助商与工程经验的编纂Sponsors and codifying engineering lessons

Titus 刚才阐述了这样一种做法：把惨痛教训吸取一次，再将其写成规则，把人类的注意力留给真正需要它的事情。这基本上也正是你希望 AI 智能体权限管理采用的方式。接下来要介绍的是本季赞助商 WorkOS。WorkOS 提供 B2B 和 AI 原生公司向企业客户销售产品所需的身份验证基础设施，支持 SSO、SCIM、RBA，以及如今面向 AI 智能体的授权功能。WorkOS Airlock 是一种基于意图的访问控制方案。大多数访问控制只会询问你是谁。Airlock 还会在智能体尝试执行操作时，判断它当下想做什么。像“禁止任何智能体删除云资源”这样明确的规则，会以普通代码的形式运行。对于那些不太明确的情况，则由 AI 在运行时评估策略。你可以用简单的英语编写这些策略，Cloth 还能从 Notion 或 Jira 中提取你已有的策略并为你导入。Titus just made the case for learning the hard lessons once, then writing them as rules, and saving the human attention for the things that really need such. That is pretty much the same way you want permissions for AI agents to work, which brings us to our season sponsor, WorkOS. WorkOS provides the auth infrastructure that B2B and AI native companies need to sell to enterprise customers with SSO, SCIM, RBA, and now authorization for AI agents. WorkOS Airlock is intent-based access control. Most access control only asks who you are. Airlock also looks at what the agent is trying to do at the moment it tries to do it. Clear-cut rules like no agent deletes cloud resources are run as plain code. For the fuzzier calls, an AI just evaluates the policy at runtime. You write those policies in plain English and Cloth can pull the ones you already have out of Notion or Jira and import them for you.

无论是 Cloth 还是 Devin，你的智能体都通过一个统一接入点连接，而你的 MCP 服务器则位于这个接入点之后。Airlock 是构建在现有权限体系之上的新一层，这意味着智能体获得的权限永远不会超过调用它的用户。遇到有风险的情况时，Airlock 可以升级处理，交由人工审批，比如通过 Slack。这和 Titus 描述的理念一样：规则只需编写一次，把人工精力留给那些确实需要关注的调用。你可以在 workos.com/airlock 申请提前体验。 我还想介绍我们的冠名赞助商 Turbo Buffer。这是一款构建在对象存储之上的超大规模搜索引擎，速度极快，价格低廉，而且扩展性惊人。你有多少机会能实时看到一次重构的全过程？有了 TiKV 团队，我们终于能做到了。他们正在从第一性原理出发，彻底重新设计存储架构，让搜索在大规模场景下变得更快、更便宜、更可靠。Your agents, whether that's Cloth or Devin, connect through a single access point and your MCP servers are behind this access point. Airlock is a new layer on top of your existing permissions, which means that an agent can never get more access than the person who invoked the agent. When something risky comes up, Airlock can escalate to human for approval, say over Slack. It's the same idea Titus described. Write the rules once and spend human attention only on the calls that need it. You can request early access at workos.com/airlock. I also want to mention our presenting sponsor, Turbo Buffer, a ridiculously scalable, fast, and cheap hyper search engine built on top of object storage. How often do you get to see a rewrite playing out in real time? With the TiKV team, we finally can. They are completely redesigning their storage architecture from first principles to make search faster, cheaper, and more reliable at scale.

这个名为 Turbo Buffer V3 的新系统尚未投入生产环境，但已经通过了 CI。9 月启动重写时，它的性能远不如当前的生产版本 V2。TiKV 团队一直在极致优化查询计划，直到它们达到或超过 V2 的速度；从优化开始到 V3 正式上线，他们始终公开进行这项工作。看到他们取得的进展真是太棒了。新系统在大多数指标上，原本比 V2 慢 10 到 100 倍，如今在冷向量搜索、按 attitude 排序或混合搜索等场景中，速度已经快了好几倍。V3 在全文搜索等方面仍然较慢，但现在只慢 1 到 2 倍，而刚开始进行性能极致优化时则慢了 100 倍。TiKV 团队还在开发日志中分享了具体的优化方法，包括分组计数聚合、压缩列编码、批量评分等，还有更多内容。The new system, called Turbo Buffer V3, is not yet in prod, but it already passes CI. And when the rewrite started in September, it was not nearly as performant as the current production version, V2. The TiKV team had been perf maxing query plans until they are fast or faster than V2, doing all this in public all the way up to the V3 production launch. And it's so cool to see their progress. The new system went from being 10 to 100 times slower across most metrics to being several times faster on things like cold vector search, order by attitude, or hybrid search. The V3 system is still slower in areas like full-text search, but only one to two times slower versus 100 times slower when this perf maxing started. And the TiKV team is sharing exactly how they optimize things in their development logs with things like group count aggregation, compressed column encodings, batch scoring, and many more.

目前，这些成果中有很多都是基础性工作，但接下来几周，团队会展示一些非常酷的系统层面工作。不过等等，团队为什么要全面重写？因为搜索正在变化，Turbo Buffer 也在变化。TiKV 最初是一个向量数据库，但如今它已不再是向量数据库，而是发展成了一个面向搜索的高性能数据库。V3 去掉了向量主索引，所有索引都将共用同一套列式存储系统。每个查询都会由向量化查询引擎执行。这种做法在搜索数据库中并不常见，但它会让数据库速度非常快，也就是说，总之就是非常快。Turbo Buffer 团队正在记录这段历程，你可以访问 turbobuffer.com/v3 跟进。看着它一步步构建起来，真是太有意思了。A lot of these wins are basic foundational work right now, but the team will be showing some very cool systems work over the next few weeks. But hang on, why is the team doing a full rewrite? It's because search is changing, and so is Turbo Buffer. TiKV started as a vector database, but it is no longer a vector database. It has evolved into a high-performance database for search. The V3 discards the vector primary index, and all indexes will share the same columnar storage system. Every query will run on vectorized query engines, which is something you don't usually see in search databases, but which will result in both very fast and just generally a very fast database. The Turbo Buffer team is keeping a work log of their journey and you can follow along at turbobuffer.com/v3. It's a blast to see how it's being built.

在 Google 撰写软件工程内容并指导提升可读性Writing Software Engineering at Google and readability mentoring

说到那些艰难的教训以及把它们记录下来，我们能聊聊《Google 软件工程》这本书吗？这本书让你颇为人熟知。这个想法是怎么来的？这本书是怎么一步步成形的？最初是什么促使你着手写这本书的？Speaking of hard hard lessons and documenting them, can we talk about software engineering Google, the book that you're quite well known for? How did the idea come? How did it come together? What was your motivation to start with?

所以，这大概是在“嘿，也许我们会推出开发者工具”这个阶段的尾声。也许我们得解释一下为什么 Google 的开发者工具会是现在这个样子，不然就有点像是外星人降临，想塞给你一些在你的世界里完全说不通的东西。我们之所以有底气去接下这类任务，部分原因是我们一直在大规模地做重构，到处都是。你会碰上每个工程师都觉得是解决自己问题的巧妙办法的东西，这也意味着，我那帮古怪的同伙遇到过太多这种情况了：“哦，没错，我看得出你当时为什么觉得这是个好主意。但别这么做。”遇到这种事，我们比外面任何人都多得多。So, this was uh a little bit at the tail end of hey, maybe we'll ship the developer tools. Maybe we'll need to explain why Google's developer tools are the way they are cuz otherwise it'll be a little bit of like aliens came down and they're trying to give you something that doesn't make any sense in your world. Part of the reason that we had the hubris to like tackle that sort of task was because we had been doing this refactoring at scale, you know, everywhere. And when you run into everything that any engineer thought was a clever solution to their problem, it meant that the my cadre of weirdos has run into so many Oh, yep, I can see how you thought that was a good idea. Don't do that. Like more than more than anyone else out there.

嗯，你说的可是业内最身经百战的一群人，因为你们长期以来一直在负责这些大型系统。Well, you're talking some of the most kind of battle-scarred people in the industry just just because you're working on these large-scale systems for such a long period of time.

而且这不是生产环境里积累的实战经验，而是测试和本地代码设计方面的实战经验。行业里的其他人都有一大堆生产环境经验，而我的工作在代码合并后就结束了。我对开发、API 设计、测试，以及如何让代码库始终保持可用，比大多数人都懂。嗯，但这也意味着，我说不好，某种程度上我算是个局外人。And it's not the production battle scars. It's the like testing and like local code design battle scars. Like everyone else in the industry has like all this production experience and like my job ends at merge. Like I know more about development and API design and test and keep the code base as an artifact working than most. Um but it does mean I don't know. I'm kind of an outsider in that sense.

嗯，有意思的是，我的意思是，这本书非常非常详尽地讲述了如何投入生产，但没有涉及运营部分，我想这大概就是这本书的历史吧。Well, interestingly enough, the I mean, the book is very very thorough on how it gets to production, but it does not cover the operational part, which I guess it's it's the history of the book.

没有一本历史书……嗯，那样的话，这本书的篇幅就会是现在的两倍。你是怎么把这本书整理出来的？你写了其中一些部分，谷歌里的其他人则写了不同的章节。There isn't a history book, which Well, then the this book would be like twice as long. How did you pull that book together? Because you wrote some parts of it. Other folks inside of Google wrote different chapters of it.

所以，这非常符合 SRE 系列书籍的精神。嗯，就是尽量请某个主题的专家，或者一位专家来贡献一些有用的内容。呃，书封面上的三个名字——我自己、Hiram Wright 和 Tom Limoncelli——Hiram 和我算是这项工作的技术负责人。Tom 也非常懂技术，不过多年来他一直是我们的技术写作伙伴。So, it's very much in the spirit of the SRE books. Um like try to get the expert on or an expert on given topics to contribute something useful. Uh and then the three names on the front of the book, myself, Hiram Wright, and Tom Limoncelli, Hiram and I were kind of the technical leadership for that. And Tom has is plenty technical, but is has been our tech writer friend for many many years.

嗯。呃，他负责了很多编辑、结构和组织方面的工作。但 Hiram 和我一直是搭档：Hiram 生成了数百万处修改，发给我审核，而我有权限审核代码库里几乎所有内容。所以大家都知道我们俩是那两个收拾烂摊子的人。我们因此也积累了不少经验，所以这件事就由我们牵头了。接下来要做的就是找到专家来写出高质量的内容。有些内容一开始就很棒。很多内容都得靠……你知道，试上几次，碰巧顺利之类的。Mhm. Uh so, he handled a lot of the like editorial, structural, organizational stuff. But Hiram and I had been the tag team of uh Hiram generated millions of edits uh and sent them to me for review, and I had the permissions to review almost everything in the code base. And so, like everyone knew us as like the those two guys that clean everything up. So, we had those scars, and so we led that. And then the trick was like finding the experts to write something high quality. Some of those were great from the start. A lot of that took a, you know, bit of goes right and stuff.

迭代，没错。嗯，整个任务实际上持续了将近两年。当然不是全职投入。大部分时间里，我们最多可能只投入了四分之一到一半的工作时间。嗯，不过我们确实从太多人那里收集了太多文本，直到看到那本书的印刷版，我才意识到我们做得有多超量。我当时就想：“哇，这也太厚了。”Iteration, yeah. Um the whole task was actually almost 2 years. Uh certainly not full-time. Like we were at most probably putting in quarter to half-time in most of that time. Um but yeah, like we wrangled together way too much text from way too many people, and I don't think I realized just how much we overshot until I saw a printed copy of that book. I was like, "Wow, that's huge."

是的，即使在今天，我也确实推荐这本书，因为它能让你很好地了解当时 Google 是如何运作的。显然，后来它一直在发展变化，但书里讲到了一家公司如何从零起步，构建重要的生产系统，同时也形成了许多现在看来可能没那么合理的做法。你还谈到了单体代码库、严格的代码审查流程，以及 Google 的可读性审查流程。也许我们可以把这当作 Google 的一项特色来聊聊：据我所知，当年 Google 是唯一一家在代码审查时，不只是由负责系统某个部分、了解相关情况的工程师审查代码并确认没问题，还会进行可读性审查的公司。什么是可读性审查？Yeah, and even today, uh I do recommend the book because it gives a really good understanding of how the Google at the time worked. Obviously, there's been evolving since, but how a company going from zero to building important production systems came over with a bunch of stuff that might not make as much sense. And you talk about things like monorepo, like the stringent code review process, how there's a readability process at Google, and maybe we can talk about that as as part of Google is the only company I know where for code review, back in the day, they didn't just have code review like an engineer who owns this part of the system and understands reviews it and says it's okay, but that you had a Google had a readability review. What is readability review?

所以，对于任何要合并的更改，参与其中的人——无论是作者还是审阅者，或者作者和审阅者——都必须具备两种不同的权限。第一种是所有权权限。也就是说，某人必须在获准修改这些文件的人员名单中。第二种是某人必须通过认证，证明我们相信你了解如何用相应语言在这个代码库中编写符合惯例的代码。这是为了尽量确保所有内容相对一致，遵循通用模式，而不是动不动就重新发明轮子——因为一致性具有战略价值。至于可读性流程，则要求有人通过相关认证。那么要怎么获得认证呢？最初的做法是，员工编号为三的那个人会和每位新员工坐下来，带着他们完成第一次代码更改。So, for any change that's going in, uh someone that is involved, either the author or the reviewer or author or a reviewer, has to have two different permission bits. First is that ownership thing. So, someone has to be in the list of people that is authorized to change these files. And the second is someone has to actually be certified in we believe you understand how to write idiomatic code in this code base in that language. And this is a step towards trying to make sure that everything is relatively consistent and that there's common patterns and you're not like reinventing the wheel uh because the strategic value of consistency and so the readability process is someone has to be certified for that. How do you get certified for that? And initially that came as employee number three sat down with every new employee and walked them through their first change.

那种做法已经无法扩展了，于是他们找来了一群其他人，试着代替 Craig 的角色。他们会带着你完成第一次重大的实质性改动。随着时间推移，情况逐渐变成，大多数改动都不是像从零开始编写一个新组件，而是在现有产品上做些小修改、添加一个功能之类的。所以，要找到一个内容足够扎实、能一次性证明你什么都懂的任务，其实挺难的，整个过程也越来越像一种入门刁难仪式。于是，多年来，我觉得 Java 团队的人开始把这种一次性的做法转变为一种明确的导师计划。你照常完成工作，等团队审核通过后，我们会从 Java 导师池中轮流指派一个人来检查，看看有没有什么实质上值得点评的内容，以此提升代码质量，并确保代码符合其他代码的规范。That stopped scaling, so they got a bunch of other people to try to proxy being Craig. And they would walk you through your first big substantive change. And over time it got to the point where most change was not like I am writing a new component from scratch. It's an existing product, like you're making little edits here and there, you're adding a feature or whatever. So, finding something that was meaty enough to like demonstrate in one go that you knew everything it was kind of hard and the whole thing felt a little bit more like a hazing ritual. And so, over the years uh I think the I think people in Java started it moved from that sort of one shot to being explicitly kind of a mentoring program. Uh you do your normal work and after your team has signed off on it, then we will round robin assign someone from the pool of like Java mentors to go through and see like is there anything like substantively like interesting worth commenting on here to kind of up the quality of the code and make sure that it matches the rest of the norms.

你可能会注意到，这意味着如果你所在的团队已经有很高的标准，那可能就没什么可评论的，对吧？你大概很快就能毕业。And you might notice that means if you're on a team that already has great standards, there's probably very little to comment on, right? And you'll probably graduate pretty quick.

是的。而且如果你不愿意学这些课程中的任何一门，那你可能要很久才能毕业，甚至根本无法毕业。呃，所以整个事情就慢慢发展成了那样。我们还把这种导师指导方式扩展到了其他所有的可读性语言中，这么多年来一直都是如此。我至少有几年没再了解过这方面的情况了，不过……Yeah. And if you're not and you choose not to learn any of the lessons, you will probably graduate very slowly, if at all. Uh and so that the whole thing kind of grew into that. And we expanded that sort of mentorship approach into all of the other readability languages and that's been the norm for a bunch of years. I haven't checked up on it since, you know, for at least a couple years, but

但这很有意思，因为在我看来，这似乎把代码审查变成了单纯深入学习一门编程语言的过程。这是有意为之，还是只是附带产生的结果？But it's very interesting because it feels to me like this turns code review into into just education in the depth of a programming language. Was this by design or was it just a byproduct?

我认为这绝对是有意为之。至少在我参与推动的那些部分，肯定是有意设计的。嗯，不过是啊，我差不多三年前离开 Google 的时候，Readability 项目基本上由我全面负责。我认为那可能是科技行业规模最大的教育项目，甚至可能是全世界规模最大的，因为在任何一个时点，都有数万人参与其中。I think it's absolutely by design. Certainly at the parts of it where I was pulling any of the strings was definitely by design. Um but yeah, when I left Google, uh you know, almost 3 years ago, readability was kind like I was kind of the overarching owner for the readability uh program. I would argue that might be the largest educational program in tech or maybe in the world cuz there were tens of thousands of people participating in that like at any given moment.

然后你就是通过加入 Google 参与其中的，当时你别无选择。不是自愿的。对。所以肯定有些人对此特别不爽。And then you just participated by by joining Google then you had no choice. It wasn't like a voluntary. Right. And so certainly some people were super pissy about it.

不过我想，这里面还有个目标，不只是说，好吧，第一步，你得处理可读性专家给你提的意见。第二步，你大概会想，既然你还有点自尊心，应该会希望他们少提点意见，因为这挺丢人的。然后第三步就是，你知道吗？好吧，我现在已经完全不会收到意见了。其实我想自己也成为一名可读性专家。那就是另一个层次了。然后第四步，现在轮到你给别人反馈了。我想，也许通过这些反馈，你会认识一些人，也许开始建立某种关系——我不知道，师徒关系、友谊之类的，谁知道呢。But I guess there was also a goal where it wasn't just about like okay, so step one is you need to address the comments that readability expert puts on you. Step two, you probably say like I'd like to get fewer comments on them if you're if you have any sense of pride cuz it's kind of embarrassing. And then step three is like, you know what? Okay, I now get zero comments. I actually want to become a readability expert myself. And then that's different level. And then step four is now you are giving feedback. And I guess through that feedback maybe you meet people, maybe you start to form some, I don't know, mentorship, friendships, who knows.

没错。你还能看到代码库的其他部分，看到别人正在做什么，了解可能正在应用的其他技术；这就像一个规模庞大、悄然运作、藏在水面之下的信息共享机制。Yeah. And you see other parts of the codebase, you see stuff that other people are doing, you learn about other tech that might be happening, like it was a huge, like, subtle, below-the-waterline, like, information-sharing program.

团队、心理安全感与学习Teams, psychological safety, and learning

在书中，你写到了团队的重要性，我来引用一下你的话。嗯，在编程领域，独行的手艺人极其罕见；即使真有这样的人，他们也不会凭一己之力创造出超凡成就。他们的成就总是源于灵感的火花，随后则是团队的英勇协作。优秀的团队善于充分发挥超级明星的作用，但整体始终大于部分之和。然而，打造一支明星团队难如登天。In the book, you write about the importance of a team, and I'll quote you. Uh in the realm of programming, lone craftspeople are extremely rare, and even when they do exist, they don't perform superhuman achievements in a vacuum. Their always the result of a spark of inspiration, followed by a heroic team effort. A great team makes brilliant use of a superstars, but the whole is always greater than the sum of the parts. But creating superstar team is fiendishly difficult.

是啊。我不觉得那一章是我写的。那是在那本你也是合著者的书里。所以，呃，我想反思一下这件事，尤其是人工智能，因为现在我开始听到更多人说，是啊，过去我们谈论的是 10 倍工程师，一直到……一直到 1，一直到 22、20、23。Yeah. I don't think I wrote that chapter. It's in the book that you are a co-author of. So, uh I wanted to reflect on this, especially with AI, because now I'm starting to hear a lot more people say, yeah, in the past we talked about the 10x engineer, up to up to one up to 22 20 23.

关于这一点，我现在开始听到有人说，哦，现在有了“100 倍工程师”——这类工程师本身能力很强，也特别善于运用 AI。我们还听说，有些人独自一人，借助一大批 AI 智能体，完成了堪称英雄壮举的工作。所以我想问问你：随着 AI 工具越来越多，“团队”这个概念还站得住脚吗？那优秀团队这个概念呢？on that. But I am now starting to hear people say, like, oh, there's now the 100x engineer, which is this engineer who is a great engineer, uses AI amazingly well, and we are also hearing stories of individuals doing heroic efforts by themselves and with a bunch of AI agents. So, I just wanted to ask you how the concept of a team holds up as we have more AI tools. And the concept of a standout team.

是啊。所以我觉得，不管你在 AI 信奉者光谱上处于什么位置，团队依然至关重要。就算你相信智能体是唯一的答案、也是唯一的前进方向，我们仍然是在管理这支智能体团队。我听到越来越多的人谈到，现在的问题是，我们需要把每个工程师都变成一支智能体团队的工程经理。但我们既没有接受过这方面的培训，也不具备相应的技能或背景。我们就这么要求他们去做一件事，却没有提供任何框架或指导。另一种看法是，把 AI 和智能体当作你的工具、你的 IDE，但与你并肩工作的仍然是周围的人类团队成员。这依然是团队协作。我觉得，你和智能体之间的社交动态之类的东西确实有所不同，我就斗胆说一句：智能体没有感情。Yeah. So, I think, regardless of where you fit on the spectrum of, like, AI believerism, I think the team is still critical. Like, if you believe that the agents are the only answer and the other direction forward, we're still managing that team of agents. And I've heard increasing number of voices talking about it as the problem right now is we need to make every engineer into an engineering manager for a team of agents. And we don't have the training or skill set or background to be have done that. Like, we're asking them to do a thing with no no scaffolding or guidance. The alternative is you think of the AI and the agents as your tools, your IDE, but it is still you in conjunction with the team of humans around you. It's still team behavior. I think there are certainly differences in the social dynamics and things like that between you and the agents, which I'm going to go out on a limb and say the agents don't have feelings.

他们绝对不会。对吧？不应该。让我们先坚持这个观点一会儿。嗯，不过，呃，是的，我觉得理解、清晰沟通，以及能够把事情写下来、把脑子里的想法表达出来，仍然是一件相当重要的事。是的，我觉得归根结底，无疑还是团队。软件工程是一项团队运动，就是这样。They definitely do not. Right? Should not. Let us hold that line for a bit. Um, but uh yeah, like I think understanding, clear communication, and like being able to write things down and get it out of your head is still, you know, a substantial important thing. Like I Yeah, I think it is still unquestionably is still teams at the root of it. Software engineering is a team sport, period.

另外，我想有一个相当简单、甚至有点天真的方法，可以证明这大概仍然成立：看看一些领先的 AI 公司和 AI 实验室，比如 Anthropic 和 OpenAI。和那里的人交流时，我会看到一些特别出色的人才，他们以团队的形式协作。比如 Claude Code，他们很巧妙地让 Boris Cherney 成为对外代表，他创造了 Claude Code，而且我觉得他做得非常出色。这让一切显得很有人情味：这是一个真实的人，但 Boris 背后还有一个团队。Also, I guess just one like pretty like naive way to just prove that this is probably still true is if we just look at some of the leading AI companies, the leading AI labs, the Anthropic's, the OpenAI's. When I talk to people there, I see standout individuals who are working as a team. You know, like Claude code, for example, they're they cleverly have a public face in front of both of them, Boris Cherney, who created it, and I think he did an amazing job. It makes it very relatable. This is a human, but there's a team behind Boris.

是的。你看我跟那个团队见面时，就能看出他们配合得很默契。他们一起工作，彼此信任。你知道，比如有时候鲍里斯会去度假。Yeah. And that team, you can when I met them, you can tell that they gel. They work together. They trust each other. You know, like at some point Boris will be on holiday.

对。你不会知道，因为事情就是这样发生的。对。就像你刚才说的那个重要关键词，对吧？信任。对。这其中很大一部分都关乎心理安全感。另一件事，我觉得这对 AI 实验室来说很自然，但目前对行业其他部分还没那么突出，那就是你会在实践中不断学习。你看看所有研究，比如 DORA 关于这类事情的研究，或者任何关于生产力、团队效能之类的研究，归根结底总是离不开文化、心理安全感，以及获得学习的许可。好吧，就是允许我承认自己有些东西不懂；就是鼓励彼此学习；就是鼓励分享自己的错误，这样团队只需要犯一次错就够了。无论是 lint 规则，还是 SRE 复盘文化，科技行业里每一种有效的组织架构和组织机制，实际上都是为了促进信息流动和学习。Right. You will not know because things just happen. Right. Like you said the important keyword, right? Trust. Right. Like a substantial part of this is the psychological safety aspect of it. The other thing, which I think is natural for the AI labs, but hasn't been nearly as dominant for the rest of the industry yet, is you're learning as you go. And if you look at all of the research, you know, like Dora research on stuff or any research on productivity or team efficacy or any of those things, like at root it always boils down to culture, psychological safety, and the permission to learn. All right, it's the permission to admit that I don't know something. It is the incentive to learn from each other. It is the incentive to share your mistakes so that the team only has to do that once. Your lint rules or SRE postmortem culture, every effective structure and organization in tech is actually about information flow and learning.

我觉得这确实是个很棒的视角。嗯，我很喜欢 Cat Hicks，她是一位研究科技领域心理学的学者。比如她的书《软件团队心理学》就写得非常好。她经常会谈到这些事情，对吧？嗯，类似地，我的一些朋友正在推出一本关于谷歌平台工程的书，目前已在 O'Reilly 上发布了早期章节。我可能写了其中关于教育的一章。And I think a really great perspective on that. Um I love Cat Hicks, uh the psychology researcher for tech. Like her book, The Psychology of Software Teams, is beautiful. And like she talks about, you know, these these things a lot, right? Um similarly, there's a platform engineering at Google book that some of my friends are putting out. This early release chapters on O'Reilly. I might have written the chapter on education for that.

呃，所以非常令人惊讶地——或者说，并不令人惊讶。对。不过，是啊，教育就像是强大的根基，能让我们尽可能少犯这种错误。把我们做过的事情编纂成规范。让人们可以承认自己不知道，并不断成长，因为这不是一次性的游戏，而是一场迭代的游戏。随着时间推移，如果你的团队下次表现得更好，你也会做得更好。Uh and So very surprisingly {slash} not surprisingly. Right. But yeah, like education is the powerful root for like, let's make this mistake a minimum number of times. Let's codify what we've done. Let's give people permission to admit they don't know and to grow because it's not a one-off game. It's a iterated game. And you'll do better over time if your team is better next time.

我想回到心理安全这个话题。大约5到10年前，我们在工程领导力圈子里经常会谈到它。当时大家普遍都明白，一个好的团队应该让人感到安全。比如说，如果你作为工程师犯了错，导致服务中断——确切地说，就是你推送了一段代码，而这段代码导致了服务中断——我们应该做一次无责复盘，而不是说：“嘿，是 Gergely 推送了这段代码，导致了服务中断。”因为这样一来，我的意思是，我会觉得非常糟糕。我们应该讨论的是，比如说，我们怎么才能从系统层面避免这种情况？为什么测试没有触发？为什么他刚加入团队时这段代码就立即发布了，或者她刚加入团队时就立即发布了？也许完善一下入职培训之类的就能有所帮助，诸如此类。I want to go back to psychological safety because back about 5-10 years ago, we kind of would talk so much about it in engineering leadership circles. This was pretty well understood that you know, a good team feels a safe team. If you, for example, make a mistake, you cause an outage as an engineer, like literally, you push a code and that code causes outage. We should have a blameless postmortem where we don't say that, hey, Gergely pushed this code and he caused the outage cuz that's now, I mean, I feel terrible and but let's talk about, like for example, how could have we avoided this at a system level? Why did a test not fire? Why was it rolled out immediately when he was a new joiner on the team or she was a new joiner team like maybe some onboarding could have helped yada yada yada.

那么，你如何定义心理安全感？它为什么重要？尤其是，假设我只是在唱唱反调：比如我们谈到那些懂很多东西的聪明工程师时，心理安全感对我们真的那么重要吗？毕竟我们应该懂自己的专业，对吧？我就会想，行吧，我有点在把自己的情绪抽离出去……What how do you define psychological safety and why is it important? Especially just playing devil's advocate like when we're talking about smart engineers who know stuff like is it all that important to us cuz we should know our thing, right? I'm just like go I'm kind of removing my emotional

对。对。但在这儿。对。呃，我们应该了解自己的东西。没错。所以我想说，这个数据一直有点难以找到依据，不过我和 Dora 的人聊过之后，研究中有一点让我特别喜欢：我们可以根据你们在心理文化问题上的得分，解释你和你的团队能否达成目标这一结果中 30% 的差异，对吧？也就是说，我们可以给团队做一份 15 道题的评估，题目可以是判断题，也可以采用李克特量表，然后预测你们能否达成目标的 30%。这简直不可思议，对吧？这比任何其他信号都更有预测力。好吧。你觉得我们都是工程师，这一切不过是电脑和技术，情绪跟这毫无关系。那你给我找找看，是否有任何东西能成为哪怕远不及它这么强的成功预测指标。Yeah. Yeah. But here. Yeah. Uh we should know our thing. Sure. So I would say and it's been a little hard to like root this uh stat, but from talking with people in Dora, the research the one thing that I love was we can explain 30% of the variance in whether or not you your team will hit its goals based on how you score on psych culture questions, right? Like we could give you a 15 question true false or maybe Likert scale like but like a 15 question assessment for the team and predict 30% of whether or not you will hit whatever your goals are. That's insanity. All right? That is more powerful than any other signal. Like, okay. So you think that we're all engineers and this is all just computers and tech and emotions have nothing to do with it. Find me anything that's even remotely that powerful predictor of success.

这说到底是人的问题，对吧？回到刚才的话题，对吧？这不是一锤子买卖，而是一场重复博弈。我经常引用 Fred Brooks 在《人月神话》中的文章，对吧？“外科手术团队”那一章是我在那本书里最不喜欢的一章，因为它的组织方式仿佛我们只会做一个项目：找最优秀的人来做这件事，让其他所有人都在他的指导下搭建工具、编写文档。这种模式非常等级森严，对吧？而且权力关系也很不正常。是啊。对吧？但如果你只需要完成一个任务，这种做法或许说得通。可从博弈论的角度来说，我们参与的是一场重复博弈。这不是囚徒困境，而是重复囚徒困境，所以策略也不一样。策略就是找一个能在监督下完成任务的最初级成员，让他在过程中学习成长，同时你也能得到还不错的结果。It's a people problem like period, right? And going back to, right? It's it's not a single shot game. It's an iterated game. I regularly cite Fred Brooks in the Mythical Man-Month essays, right? And in the surgical team like at the surgical team is my least favorite chapter in that book because it's structured as if we're only ever going to do one project. Get the best person to do this, get have everyone else build the tools and do the documentation under them. It's very hierarchical. Right. And it's very like power dynamics mad. Yeah. Right. But it might make sense if you're only ever going to do one task. Instead, we're playing like in a game theory sense. It's not prisoner's dilemma, it's iterated prisoner's dilemma. There's a different strategy. And the strategy is find the most junior person that can do it with supervision so that they learn and grow and you still get a decent outcome.

接下来，比如说，级别更高的人可以去解决他们还不知道该怎么做、或者其他人都无从下手的问题，对吧？只有这样才能构建出促成成长的机制。但要实现这种成长，人们就必须愿意承认自己有不懂的事情。这又会直接回到心理安全感和学习型文化，对吧？如果一种文化重视信息共享、学习和成长，你就会成功。And that next, like the higher level people can solve something that they don't know how to do yet or that like no one else can tackle. Right? This is the only way to like structure it so that growth happens. But in order for that growth to happen people have to be willing to admit that they don't know a thing. And like that brings you straight back to psychological safety and learning culture, right? Like if it is a culture that highlights information sharing, learning, and growth you will succeed.

你提到，AI 实验室已经把这视为理所当然了，而我正要……因为他们不知道自己是什么样的。好吧，我换个说法：AI 实验室有几方面进展得不错。首先，业务蒸蒸日上。他们不断发展，收入在增长，客户在增加，融资在增加，员工人数也在增加。他们的团队只会不断壮大，正处于高速增长期。我们见过 Netflix 和 Uber 这样的公司高速增长，而现在的速度甚至更快。你的股权价值也在上涨。所以你不必担心绩效评估之类的事情，因为绩效评估通常很重要，是因为它关系到我能拿多少奖金之类的。但如果你待在这样一家不断发展的公司，而且你的股权价值也在上涨，那么只要专注于帮助公司取得成功，不管你的职衔是什么，你的经济回报就有了保障。其次，因为他们在开发新技术，也知道没人真正懂，所以他们就会直接说：“好吧，我也不知道，我正在向你学习。”And you mentioned that the AI labs already take this for granted and I'm going to Because they don't know what they're like Well, I'm going to paraphrase it like with the AI labs have a few things going. First of all, business is booming. They are growing. Revenue goes up. Customers goes up. Funding goes up. Headcount goes up. Their teams are only ever expanding. They're in hypergrowth. Like we've seen companies like Netflix and Uber in hypergrowth, this is even faster. Your equity also goes up. So you don't need to worry about things like performance reviews because performance reviews are typically important where like how much bonus am I going to get, how much. But when you're at a place that goes like this and your equity goes up, your financial part is taken care of just by focusing on helping the company succeed regardless of your titles. Second of all, because they're building new technology and they know no one knows, so they just tell okay, I don't know, I'm learning from you.

这是我学到的。所以这一切都是自然而然的。相比之下，那些可能不会这样增长的公司，或许也在使用 AI，但人们说“我不知道”的动力就没那么大了，因为绩效评估就要来了。你想显得自己最聪明，不想让别人觉得“这个人老是说自己不知道”。你的奖金会更低。你甚至可能会被列入绩效改进计划，因为你现在所在的公司每年都会裁掉 6% 的员工。Here's what I learned. So it's just all natural. Whereas compared to company that might not grow like this, they might still be using let's say AI, but now there's less of an incentive to say I don't know because there's a performance review coming up. You want to look like the smartest. You don't want people to say like well, this person says I don't know a lot. Your bonus will be lower. You might be put on a performance improvement plan because you're now at a company that every year let's go a 6% of people.

对。而你的目标突然就从“我就是不想待在那里”变成了“我想保住这份工作，但这份工作保不住了”。现在变成了……Right. And your goal is suddenly going from like I just don't want to be there. I want to hang on to this job, but it's not hanging on. It's now

嗯哼。而且你现在可能也会提防队友，因为出现了内部竞争。你想独占那个项目。对。所以这就是一个很大的区别。Uh-huh. And you also you're now wary of maybe your teammates because now there's internal competition. You want to hog that project. Yep. And so this is a huge difference then.

没错，这影响巨大。比如说，如果你开始相信团队的成果才是你个人成功的关键，那你就更容易意识到：好吧，我不一定非得拿下那个光鲜亮眼的任务。只要有人把这件事做好，团队就能成功，而下一次说不定就轮到我了。可要是事情演变成个人主义，变成我不信任对面那个人，或者不信任就在我身边、和我并肩的人——明明我们属于同一个团队，却还得勉强维持，争抢关注和成功的机会——那就不是创新和成长的良方。这只会导致停滞，甚至更糟。Yeah, it's huge. Like if you get into the mode of believing that the team outcomes are what matter for your own success, then it is much easier for you to realize like okay, I don't have to have this one shiny task. Like the team will be successful by virtue of someone doing this and it might be my turn next. If when it breaks down into that like individualism and like I don't trust the guy across the way from me or you know, right shoulder to shoulder to me like even though we're on the same team, we're scraping by and like you know, fighting for attention and success. And that's not a recipe for innovation and growth. Like that is a recipe for stagnation and just bad.

裁员对工程文化造成的隐性代价Layoffs and the hidden cost to engineering culture

显而易见的一点，我想你也知道，裁员对心理成长没什么好处，甚至会造成严重伤害。嗯。根据你的观察，你能跟我说说吗？我们都经历过，对吧？2022、2023 年也发生了一连串裁员。现在公司又开始裁员了。当时裁员是因为利率问题、零利率时期过度招聘，以及增长开始放缓。现在有些公司公开表示，裁员是因为 AI。有些公司没那么公开，但我们后来发现，比如 Meta 就想缩减团队规模，因为他们觉得有了 AI 就够了。从你的观察来看，在一家公司发生裁员后，软件工程师的表现、工作方式和想法会发生什么变化？可以谈谈你的亲身经历，以及你和别人交流时听到的情况。One of the obvious things that I assume you know, is does not do good for psychological growth or is terrible for it is layoffs. Mhm. Can you tell me based on your observation and then we've seen right? Like you we've all been part of it and in 2022 2023 there has been a series of layoffs. Right now companies are doing it again. Back then it was to do with all all this interest rates and over hiring during zero interest rates and growth kind of going down. Now some companies are are actually openly saying that it's AI. Some are not as openly, but we find out that meta for example wanted to reduce team sizes because they thought that I will be there. From your observations at a company where a layoff happens, how does it change how software engineers show up, work, think? Speaking both about your experience and people you talk with.

我是说，这很让人有压力。嗯，我经历过所在地区裁员的情况，那之后好几个星期甚至几个月，每次一对一谈话一开始都会问：“那你最近怎么样？”“你还应付得来吗？”这会带来非常大的负面绩效影响，因为大家会觉得：“好吧，我们得先在情绪上互相支持，然后才能真正回去做工作。”我非常怀疑，高管在核算这一切时，是否考虑到了生产力和时间的大量损失。比如说：“对，大家压力都很大。大家都在花时间更新简历，以防下一个被裁的是自己。大家把一对一谈话的时间用来做心理疏导，而不是规划工作。”I mean, it's stressful. Like uh it I've had experiences of there being layoffs in the area and just it'll be weeks or months of every one-on-one starts with, "So, how are you doing?" Like, "How are you coping?" Like, there's this huge amount of yeah, negative performance influence of like, "Okay, we got to like emotionally support each other first before we actually even get back to doing like the work." And I am very skeptical that in the executive accounting on all of this that they're taking into consideration just the sheer amount of, you know, lost productivity and lost time from like, "Yeah, people are stressed. People are spending time brushing up their resume in case they're next on the chopping block. People are spending that one-on-one time like in therapy instead of in planning."

嗯，这一切都带来了巨大的隐性成本，而且真的很打击人的积极性。它让人深刻意识到：好吧，这不过是一项工作上的义务，不是什么生活方式的选择。如果我额外付出，却不能因此得到更多保障，那又有什么意义呢？你知道吧？而且这背后还牵扯到很多文化层面的包袱。我其实很喜欢 Adobe 的一点是，他们很长一段时间里都由同一位 CEO 领导。他刚刚卸任，现在已经有了接任者。不过，大衰退期间他就在公司了。当时公司裁了一些人，他亲眼看到这对士气、公司生产力以及其他各方面造成了多大的伤害，也从中吸取了教训：我们当时觉得这么做在数字上说得通，但这对公司的精神内核并没有好处。Uh it's it is a huge hidden cost to all of that. And it's really demotivating. It drives home like it is a reminder that okay, this is just a business obligation. This is not a lifestyle choice. And if me putting in extra doesn't give me extra safety on this, then what's the point, you know? And like it there's a lot of cultural like baggage that happens for that. And it's one of the things that I actually really liked about Adobe was Adobe's had the same CEO for a long time. He just stepped down. He has a replacement now. But he was there for like the Great Recession crash. And they did some layoffs at that era. And he saw how much it hurt morale and company productivity and all of the rest of that and he learned like it we thought it made numeric sense at the time, but it was not good for the soul of the company.

而那不是我们想成为的那种公司。所以，Adobe 过去几年没有进行裁员。随着优先级的重新调整，各个团队可能会有一些局部变动，但不是那种全面铺开的……And that's not the company that we want to be. And so Adobe didn't have the layoffs in the last few years. Like there's group by group like local things as things get re-prioritized, but it's not the sweeping all that

但我们看到，大多数大型科技公司都经历过这种情况，尤其是在 2023 年。是的。but we've seen that at most of big tech has had it especially in 2023. Yeah.

开发者体验、生产力与人工智能的价值Developer experience, productivity, and the value of AI

说到 Adobe，你几年前加入了 Adobe。你在 Adobe 主要负责什么？我在那里是一名资深个人贡献者，专注于开发者体验。我常说，这其实是一种委婉的说法。开发者体验本质上关乎生产力。我们只是足够明白，知道不能说我们可以衡量生产力。这并不是理所当然的。And speaking of Adobe, so you've moved to Adobe a few years ago. What are you focused on at Adobe? So, there I'm very senior IC focused on developer experience. I happen to say this is a polite fiction. Developer experience is the business of productivity. We just know enough not to say that we can measure productivity. It is not given

不像麦肯锡——我和肯就是因为这个话题才产生共鸣的。对，那真是太糟糕了。我们会在下面的节目备注里放个链接。对。所以，我们需要哪些工具、文化，以及其他所有东西，才能改善开发者体验，让你更有生产力、更高效呢？因为大多数公司在工程团队薪酬上的支出比其他任何方面都多。Unlike McKinsey who me and Ken have bonded over. Yeah. That was that's horrible. We'll put a link in the show notes below. Yeah. So, it's it's what do we need for, you know, tools and culture and, you know, all of the things to improve the experience of being a developer and make you more productive and efficient because most companies spend more on engineering comp than anything else.

所以，今天你一直在关注并致力于这件事：在 Adobe 是这样，在某种程度上，在 Google 也是如此。如今你对开发者生产力了解多少？它与 AI、编程工具、产出、指标以及所有这些东西有什么关系？我们能衡量什么？什么值得衡量？又有哪些事情很难弄清楚？So, today you've been focused on this thing about it and working on it for both at Adobe, but also to some extent at at Google. What do you know today about developer productivity? How does this relate to AI, coding tool, output, metrics, all of that things? What is it that we can measure? What is it worth measuring? And what are things that are hard to know?

是啊。我的意思是，我们一直把“生产力很难衡量，甚至可能根本无法衡量”当作不言自明的事实，因为单位到底是什么呢？前阵子我有个算是挺巧妙的想法。嗯，我说“巧妙”这个词是有意带点意味的。我想到，如果我们不知道单位是什么，经济学在这方面不是有现成的先例吗？你可以用一个指数指标，把所有可能影响这件事的因素都衡量出来，再想办法把它们有效地整合成一个指标。这样一来，你就能得到一个没有单位、但能反映趋势，而且长期来看也有参考价值的数字，可以大致以此为准。我的设想是，衡量所有那些我们认为能正面或负面反映事情是否进展顺利的指标，对吧？发布次数、测试覆盖率、PR 数量，对吧？所有这些，明白吧？Yeah. I mean, we've taken it as axiomatic that it is hard if not impossible to measure productivity because what are the units even? I had a while back sort of clever idea. Um and I use that as a loaded term. I had this idea that if we don't know what the units are, like economics has prior art for this, right? You have an index metric where you measure all of the things that might influence this and you come up with a way to effectively like basket those together. And then you have a unitless but like directionally useful and useful over time like number that you can sort of like pin to. And my theory had been to measure all of the things that we think are positive or negative indicators of something is going well. Right? Releases, uh test coverage, number of PRs, right? Like everything, right?

就广撒网吧。我最初对此的想法是，呃，你知道，就是“群众智慧”这个概念，对吧？比如，没有哪个人能估算出罐子里有多少颗糖豆，但你找来 100 个人，估算结果就会很接近。所以，我们做一个类似“我火不火”的投票，问大家更喜欢哪种？比如每周多发布一次，还是做 X 次测试，对吧？然后你就和那些相对有经验的工程师一起，反复玩这个游戏。Just cast a wide net. My initial formulation on this was uh you know, the wisdom of the crowds idea, right? Like no individual can estimate how many jelly beans are in the jar, but you get 100 people and you'll get real close. So, we do a like am I hot or not? Of like which would you prefer? Like one release per week more or X tests, right? And you run a bunch of iterations of that game with your, you know, relatively experienced engineers

是的。要弄清楚这些因素之间的线性权衡，看看哪些更重要，对吧？弄清楚这到底是什么。你可能得把一些东西去重，因为它们只是同一个统计指标换了种包装，对吧？但要找出那些具有非线性的指标。然后把它们都揉到一起，对吧？这样你就能得到一个综合指标，比如说，这就是我们的生产力数字。Adobe 正在做类似的事情，而且比我最初的设想稍微聪明一些。然后你就可以观察这个指标随着时间推移、针对某个人群是上升还是下降。后来我意识到，在这波 AI 热潮之后，这个指标无法涵盖所有情况。我之所以得出这个结论，是因为我最近发表了一篇关于开发、部署和运营的论文，其中有一点是，科技领域的影响有四种形式。Yeah. to work out the linear trade-offs between all of those To figure factors. out what matters more. Right? To figure out like what that is. You probably want to dedupe some things cuz they're just going to be the same stat in a different package. Right? But find the ones that have some non-linearity. Uh and then mush that all together, right? Now you have something that sort of gives you an aggregate, like this is kind of our productivity number. And Adobe is doing something along these lines. Slightly smarter than my initial formulation. But like then you can watch that track up or down and, you know, over time for a given population. What I've realized is that won't capture everything in this post-AI boom. And the reason that I came to that was a paper that I put out, uh the develop deploy operate paper recently, where one of the points in there is there's four forms of impact in tech.

产品是否成功，那些大家都在谈论、而且别人都比我更擅长的事情。就像，那不是我的工作。人们会不会买某个产品、会不会用某个产品之类的。There's product success, the stuff everyone talks about and everyone else is better at than I am. Like that's that's not my job. Whether or not people buy a product or or use a product, whatever.

还有净推荐值、收入，以及所有这些东西，对吧？还有计算效率，对吧？比如你在 AWS 上花了多少钱？对吧？或者如果你在发货传感器之类的东西，我对此太熟悉了。对吧？你知道，甚至像 Android 团队，也会权衡是否能把应用下载包的大小减少一兆字节，And net promoter score, revenue, like all of the stuff, right? There's compute efficiency, right? Like how much are blowing on AWS? Right? Or if you're shipping sensors and all that, so I know that all too well. Right. You know, or like even like the Android team has a trade-off for if you can reduce the size of a application download by a megabyte,

是的，它对很多指标都有影响。对。你知道，所有这些东西都是一种影响。然后还有工程效率，或者我们把它表述为工程产能，因为如果我们提升了 5% 的效率，也就是增加了产能，你并不能把这部分产能拿去做别的事。你只是有更多产能来做更多工程工作。it makes a difference for many metrics, yes. Right. You know, and so like all of those things, like that is a form of impact. Then there's engineering productivity or we phrased it as engineering capacity because if we save you know, 5% productivity gains, capacity gains, you don't get to spend that somewhere else. You just have more capacity on doing more engineering.

或者说，有一些余裕时间可以用于创新，或者在发生状况时及时应对之类的。但这些并不能像钱一样自由互换；你不会因此在另一个账户里收到钱。第四种影响形式又和 AI 有关。第四种影响形式就是改变游戏规则，对吧？也就是战略创新。比如，研究能让不可能的事情成为可能。Or having slack time for innovation or picking up when something happens, that kind of stuff. But they're not like dollar fungible, you don't get money in a different account. And then the fourth form of impact, and this ties back to the AI thing. Fourth form of impact is changing the game, right? Strategic innovation. Like research makes impossible things possible.

哦，是啊。安全性会让那些极其糟糕的事情变得不可能，对吧？但如果你改变我们所做事情的性质、成本结构等等，那就是另一回事了。我认为我们在 AI 领域看到的问题是，即便采用一种巧妙的——你知道——指数指标方法，试图捕捉生产力的整体面貌，如果你没有考虑到某项变更的价值已经发生了很大变化，那你就永远无法从信号中捕捉到这一点，对吧？我们没有任何指标能反映这种规模的变更所带来的价值已经改变了。举个例子，现在完全有可能——我常混迹于安全领域，也做很多底层的 C++ 库相关工作——你可以在几周内写出一个 JPEG 解析器。Oh, yeah. Security makes incredibly bad things impossible. Right? But if you change the nature of what is what we are doing, the cost structure, etc., then that's a different game. And the problem that I think that we see with AI, even with a clever met, you know, index metric approach to trying to capture the gestalt of productivity, if you're not looking for the value of a given change is substantially different, then there's no way you'll ever be able to capture that in the signal. Right? We don't have anything that says the value of a change of this size has changed. So for instance, like it is entirely possible at this point, and I hang out in security spaces and do a lot of low-level, you know, C++ library stuff. You can write a JPEG parser in a couple weeks.

没错，对吧？再加上你需要的任何其他功能。三年前把这句话说出口，简直不可思议。好，所以你的意思是，所有这些衡量指标真正捕捉不到的，是进行重大创新的可能性、影响，以及所需付出的努力；而如今，AI 正在推动这样的创新发生。对了，我也给你举个例子，你告诉我这是不是你说的那种情况：我有个朋友，在一家工程公司当 CTO。那是一家中型工程公司，属于一个细分行业。你知道，他们的 CTO 一直在关注发布频率之类的常见指标，也会和工程团队沟通，看看大家满意不满意。当然，他们现在也在采用 AI。他们发现，员工的效率确实提高了。私下里，这个人跟我说：“你看，我基本可以确定，我们很可能只用一半的人手，就能完成同样多的工作，然后实现现金流转正。”Yep. Right? With whatever additional features you need. That would be insane to say that word that sentence out loud 3 years ago. Okay, so what you're saying is what none of the measurements really capture is the possibility, the impact, the effort it is to do a massive innovation, which right now with AI is happening. And right and I'll I'll I'll give you also one example that I and tell me if if this is what you mean with it is there's a friend who works at a CTO at an engineering company about uh like a mid-size engineering company. They're they're a niche industry. And you know, like this the CTO they have been looking at like release frequency, all the usual metrics, talk with their engineering team, are they happy, are they not? And of course now they're adopting AI as well. They're seeing that well, people are more efficient and just privately this this person was telling me like, "Look, like I kind of know that for a fact that we could probably do the same amount of work with like half the amount of people and then we could be cash flow positive.

不过当然还有士气方面的问题。”所以他也挺喜欢那些人的。他说：“我不确定自己想不想背上这份情感负担。不过我们能看出来，有些人接受得更快，有些人慢一些。我们最后就先这样吧。”几周后，我又和这个人聊起这件事，他说：“你肯定想不到，我们可能很快就能实现现金流为正了。”我说：“怎么做到的？你们还是裁员了吗？”他说：“没有。事情是这样的，我们有个工程师来找我，说：‘我们给这个组件付了许可费。你可以把它想成一个库。它是一个二进制文件，是这个领域的一家供应商开发的，他们的软件里用到了一个高性能组件。这个组件是软件的核心部分。他们和对方有收入分成协议，要为这个组件支付大概……我也不知道，收入的 5%、10% 或 15% 吧。’But of course there's a there's a morale thing." So he's like also like he likes the people. So he's like, "I don't I'm not sure I want the emotional baggage on on me. But we can see some people are picking it up faster and some slower. And we kind of left it at that." A few weeks later I'm talking with this person and says like, "You wouldn't believe, but we're probably going to be cash flow positive." I'm like, "How? Like did you go ahead with the cut?" He's like, "No. What happened is one of our engineers came to me and said like, "We license this component. Think of a library. Like it's a binary. But that was written by a vendor in the space that has a high performance thing that they use in their in their software. It's it's a core part of it. And they have a revenue share where they pay like I don't know like 5, 10, 15% of their revenue for this component.

这太重要了。它显然是有授权的闭源软件，但它真的非常重要；要是他们自己写，得花好几年时间，组建一个五人或十人的团队，而且最后做出来的东西还不一定能用。所以不值得。”工程师过来后说：“要不我们就把规格说明给他们？因为他们围绕这个东西做了大量测试，还有一套测试框架。他们把这些交给了 AI。AI 替他们写了一个组件，速度比他们现有的更快，效果也更好，而且 AI 没有任何相关领域的先验知识。一开始他们想，也许可以把它开源，但后来他们告诉了供应商，供应商说，这对他们来说是一笔大生意。他们付钱让供应商不要开源，并把实现交给他们。这样他们就可以重新授权。突然之间，局面彻底改变了。要是这个人当时真的继续推进，比如说裁员，这位工程师可能就会得到一个……而可能没人会知道，局面原来可以因此改变。It's so important. It's obviously licensed, closed source, but it's it's really important and it would take them years of a five-person or 10-person team to write it and it might or might not work. So it's not worth it." The engineer came and said like, "What if what if we just gave the specs? Cuz they have all massive amounts of test around this thing, a test harness. They gave it to AI. AI wrote a component to them which is faster and better what they have, no prior domain knowledge. And at first they thought, well, maybe we'll open source it, but then they told the supplier and the supplier said like, it's a huge business for them. They're paying them to not open source it and to give them the implementation. Which they can re-license. And suddenly, the game was completely changed. Like if if this person would have gone ahead with, let's say, the layoffs, this engineer might have just got a and no one would might have known that the game could be changed because of this

AI有时候会让一些原本很疯狂的事情变得可能。对。没错。所以我觉得，这就是试图弥合这样一个落差的洞见：我还没看到任何基于研究的数据表明，AI带来的生产力提升超过大概20%或30%。但大家又都在谈那些所谓的10倍体验。我非常不认为它实际上真有10倍，不过……AI makes things crazy things sometimes possible. Right. Exactly. And so I think that this is the insight that tries to bridge the gap between I have not seen a research-based number that says productivity post AI is up more than like 20 or 30%. But then everyone talks about like these 10x sort of experiences. I super don't think it's actually 10x, but

嗯，是啊。但要怎么弥合这个差距呢？我觉得关键就在于，AI 的很多价值并不在于把同一件事做得更快，而在于去做更难、价值更高、你原本甚至都不会想到的事。如果你的生产力衡量方式，本质上等同于统计工厂里产出了多少件小玩意儿，而你开始生产镀金的豪华版小玩意儿，那就根本没法衡量，也无法长期追踪，因为我们根本没有办法追踪某个组件或功能的价值。这也和我们跟资深工程师交流时听到的情况相符：是的，我们的代码量增加了 70%，故障增加了 30%，功能数量没变。我们无法确定的是，这些功能的价值有没有提升？Um yeah. But like, how do you bridge that gap? And I think it's exactly this thing of a lot of the value of AI is not in doing the same thing faster. It's doing a harder, more valuable thing that you wouldn't have even thought about. And if your productivity measures are the logical equivalent of counting how many widgets are coming out of the factory, and then you start producing super gold plated deluxe widgets, there's no way to measure that or track that over time because we just don't have the tracking of what's the value of this component or feature. And that also matches with, you know, talking with senior engineers that are like, yes, we're up 70% on amount of code, we're up 30% on outages, number of features is the same. The thing that we can't know for sure is are the value of those features up?

因为……什么？你怎么，你怎么做到的？Because what's how do you how do you do that?

重新思考计算机科学与软件工程教育Rethinking computer science and software engineering education

人工智能带来的一个挑战是，它正在进入应届毕业生的就业市场。现在似乎出现了一种……一种预期。公司非常愿意聘用懂得如何使用人工智能、并且有品味和判断力的资深工程师，这些说法也常常被提起。这并不是刻意为之，但每当我和人工智能实验室的人交流时，他们总会越来越多地告诉我，他们看重品味、判断力、主动性之类的特质。我们回到教育上来吧，回到计算机科学教育上。你怎么看如今的计算机科学教育，尤其是考虑到我们知道这个行业正在发生变化？你觉得有哪些方面可能需要改变？One challenge that AI is giving uh is entering the market uh for new graduates. Uh there's now there seems to be this ex- expectation. Companies are very eager to hire senior engineers who know how to use AI and they have taste and judgement, and we have these things thrown around. It's not deliberate, but whenever I talk to the AI labs, they always tell me increasingly that they look for taste, judgement, uh agency, these kind of things. Let's go back to education. Uh to computer science education. W- What are your views of how today's computer science education works, especially for how we know the industry is changing? And what are some of your ideas of what could what's uh possibly be changed?

我稍微谈谈自己在这方面的资历，给这件事增加一些分量。呃，出书之后，我受邀参与了 ACM、IEEE 和 AAAI 关于制定计算机科学本科专业课程要求的工作。这就相当于专业学会在说：“这些是我们需要做的事。”在这项工作的指导委员会里，我是唯一一位仍在业界工作的工程师，其他人都是学术界人士。I will riff a little on my bona fides there to like to add some weight to this. Uh So, after the book, I got recruited into the ACM IEEE AAAI work on setting the curriculum requirements for an undergraduate CS degree. So, this is like the professional societies saying, "These are the things that we need to be doing." And for the steering committee for that work, I was on the steering committee, I was the only currently working engineer. Everyone else is academic.

好。是的，从某种意义上说，因为你知道，我们能教些什么呢？呃，我主要负责软件工程方面的课程要求。不过这也意味着，我很清楚这些要求具体是什么，而且多年来一直身处其中。坦率地说，呃，我曾在人工智能时代到来之前的一场主题演讲中谈过这件事：计算机科学课程体系大体上自 2000 年以来就没有实质性变化，甚至可能更早就如此了。对吧？课程里常见的内容，恰恰就是 90 年代构建数据库或操作系统所需要的东西。Okay. Yeah, in some sense, cuz, you know, it's what can we teach? Uh and I managed mostly the software engineering requirements. But it does mean that I like I see exactly what the requirements are and have been living in that space for years. And bluntly, uh and I gave a talk on this in a pre-AI keynote, uh bluntly, most of the CS curriculum hasn't substantially changed since like 2000, maybe earlier. Right? The average thing in the curriculum is exactly what was needed to build a database or an operating system in the '90s.

听起来不太妙，对吧？对于一个以创新为傲的领域来说，不是吗？还有很多这样的事情，我真的不得不问：我们教这个，是因为它相关且重要，还是因为这是传统？是因为历史原因——或者说，因为我们知道该怎么教它。对吧？或者说，因为我们知道该怎么教它。毕竟，软件工程或计算机科学系的发展历史——最早的计算机科学系也不过只有五六十年、七十年。对吧？这个领域实在太年轻了，不该因为传统就沿用那些做法。即使在 AI 出现之前，我就觉得，很多东西都得推倒重来，因为课程要求和教学内容大多都是靠不断累积形成的。你知道，就像我们只管往里塞更多内容，却把现有内容的讲授深度削减了那么一点点。That doesn't sound good, does it? Not for a field that prides itself on innovation, right? And like there's all of these things where like I have to genuinely ask, like, are we teaching this because it is relevant and important, or are we teaching this because it is tradition? And the history of or we know how to teach it. Right. Or we know how to teach it. But cuz like the history of, you know, software engineering or CS departments, like we're only at 50, 60, 70 years for the earliest CS departments. Right? Like this is a field that is way, way too young to be doing stuff out of tradition. Even pre-AI, I was like, I think a lot of this needs to be burned down because all of the curriculum requirements, all of the teaching has mostly been through uh accretion. You know, like we just throw more stuff in there and cut the amount of depth on the existing stuff by epsilon.

是啊，对吧？我觉得那样行不通。甚至在 AI 出现之前，我就一直在说，我真正想要的是，你花更多时间练习和训练，真正成为一个流利的程序员、具备算法思维的人，而不是对一百万个不同主题都只懂点皮毛。现在有了 AI，对吧？是啊，我们几乎可以保证，你整个本科阶段都不用动脑子，只要把东西丢给 AI 就行，因为它完全能应付那些程序和作业。所以我一直在主张，我们得跳出具体代码层面。我们的思维层次需要大幅提升。你得能够读懂代码，以系统思维来思考，并且从算法角度理解其结构和执行过程；但没人需要亲手实现一个链表。Yeah. Right? And like that I don't think that works. Even pre-AI, I was saying like the thing that I really want is like you spend more time practice and drill and actually become like a fluent programmer algorithmic thinker, not you have a trivia understanding of a million different topics. And now AI, right? Like Yeah. We guarantee like you can do all of an undergraduate degree without ever thinking uh if you can just feed it into an AI cuz it will do just fine on all of those programs and assignments. And so a lot of what I'm pushing for is we need to get out of the code. We need to up-level substantially. Like you need to be able to read code and think as a systems thinker and under- like algorithmically like understand the structure and execution, but no one needs to implement a linked list.

而且我们可能甚至不该教链表。这太慢了，对吧？内存本身就很慢。我们越是能够把重点重新放到设计规范上——比如精准地说明你希望发生什么——以及测试、验证、核查上，也就是确保 AI 确实完成了你需要它做的事情，对吧？如果我们能教会这些东西，那么它们对专业人士来说就会一下子变得非常相关。我的意思是，关键问题是：这还会属于计算机科学吗？还是说，计算机科学专业的招生人数会大幅下降，而软件工程项目会迅速增长？因为说实话，在 AI 时代，真正重要、也能让你找到工作的技能会是团队协作、沟通、设计、规范、测试和验证，对吧？And we probably shouldn't even teach linked lists. It's the way too slow. Right? Memory is a slow thing. The more that we can refocus on uh design specification, like precision in saying what you want to happen, and then testing, validation, verification, like making sure that the AI actually did the stuff that you needed to happen. Right? If we can teach those things, then it's suddenly perfectly relevant you know for professionals. And I think the big question is will that be CS or are we looking at CS enrollment is going to plummet but software engineering programs are going to kick up because let's be honest the stuff that's going to matter like in a AI era and still get a job is teamwork, communication, design, specification, testing, validation, right?

哦，那涉及很多软件工程，还有构建生产级软件，尤其是借助 AI……没有什么……我之前和 CockroachDB（Cockroach Labs）的联合创始人 Peter Mattis 聊过，他告诉我，他上大学时还利用课余时间开发了……Oh, that's a bunch of software engineering And also building production software especially with AI there's no like I was talking with Peter Mattis co-founder Cockroach DB Cockroach Labs and he was telling me that during his college on the side he built the

嗯。是啊。后来他得到了很多机会，然后他开发了 GTK+。我当时就在想，等等，他可是边读计算机科学学位边抽空做的。难道你不想干脆把计算机科学那部分撇开吗？我也学过计算机科学，但如果是软件工程学位，难道不该从第一天就开始动手吗？尤其是在 AI 时代。大家进来之后，第一门课让你们合作开发一个软件；另一门课也是开发软件，但要和团队一起做。第三门课是在已有软件的基础上扩展。到了第四门课……因为以我读计算机科学的经历来说，我们学了一大堆理论。我最喜欢的课，是那四年里唯一一门团队合作、真正动手开发软件的课。就这么一门。Mhm. Yeah. And he got a lot of opportunities afterwards and then he built GTK plus and I was thinking hang on like he did that on the side next to a CS degree. Would you not want just throw aside computer science? I did computer science as well but for a software engineering degree would you not want to start on day one especially with AI? People come in here and you build on one class you build one software and the other build you build a software with a team. On the third one you extend the software. On the fourth one because my experience being in a computer science thing we did a bunch of theory. My favorite class was the one team-based class where we actually built software in the four years. There was one only one.

很正常。然后我又上了一门额外的课，真正去学习 .NET。可当我进入职场时，却觉得自己像是从零开始。我想到当时没教、如今会教的那些东西，但缺少实践。我有理论知识，但肯定没有经过足够的反复练习。Normal. And then I took an extra class for to actually learn dot net and then when I got into real world it felt I was starting from scratch. I was thinking of all of these things which were not taught at the time these days are but the practice was missing. I had the theory but I definitely did not have the reps.

没错。我认为，之所以有首轮代码面试，就是因为这个。好吧，怎么才能看出一个人是否投入了足够的练习？对吧？就是那些参加编程竞赛的学生，他们在这件事上投入了足够多的时间。Right. And I would argue that the lead code interview was because of this because okay, how do you find signal that someone has put in the reps? Right? It's the students that were playing in the programming contests, right? Those are the ones that had enough time on task.

那是唯一一些稍微有点常见、向没有软件工程专长的工程师开放的岗位。抱歉。呃，对。对编程有兴趣、但没有软件工程专长的人。that was that was the only reps that were kind of a little bit get common that were open to engineers who didn't have software engineering expertise. Sorry. Uh yeah. People with affinity for programming who did not have software engineering expertise.

没错，对吧？所以从这个角度来看，我们问 LeetCode 那类竞赛风格的编程题，确实很有道理；不是因为我们需要解法来再做一道广度优先搜索题、反转一个链表，或者诸如此类的无聊东西。更重要的是，这能作为一种间接衡量，看看你是否曾身处一个需要反复练习、不断积累经验的环境里。相比之下，一个普通学位项目中真正用于编程的时间其实相当有限。你知道，马尔科姆·格拉德威尔不是提过精通一门技能需要一万小时吗？我记得是格拉德威尔说的。呃，是啊，那你上哪儿找这么多时间呢？Exactly, right? And so like it made perfect sense from that perspective for us to like ask the sort of leak code questions in the programming contest styles, not because we needed solutions to get another breadth-first search problem or reversing a linked list or any of that nonsense. But specifically because it was a proxy for you've been in an environment where you put in the reps. Whereas the amount of actual like programming time on task for an average degree is pretty modest. And you know, you go back to 10,000 hours to mastery in Malcolm Gladwell. I think that's in Gladwell. Uh and like yeah, like where are you getting the time?

而且，如果、如果、如果我回想一下那些大约在2010年代初兴起的训练营，它们在2014到2017年间开始变得非常强。它们的做法是，用三个月——三到六个月，有时甚至十二个月，不过通常是三到六个月——来培训那些此前没有计算机科学或编程经验的人。从第一天起，他们就开始动手构建应用，通常是一个前端和一个后端。他们教给学员一些基础知识，内容不算多，但学员会用三个月或六个月的时间密集实践，从零开始构建一个可运行的 Web 应用。And if if if I think back of the boot camps that have spun up in the from like early 2010s, they started to get really strong 2014 to 2017. What they did is that a 3-month 3 to 6 months sometimes 12 month, but usually 3 to 6 months, they took people who had no prior computer science or programming experience. They started day one, let's build an application which was typically a front end and a back end. They gave them the basics. It wasn't all that much, but that was a three intensive months or six intensive months of building a working web application from the ground up.

是啊。当时对软件工程师的需求非常大，所以他们被以初级工程师的级别，或者几乎是学徒的级别聘用。但和计算机科学专业的毕业生相比，他们懂得——呃——版本控制，懂 Git，懂拉取请求，懂数据库，懂前端，也懂新的 Chrome 开发者工具。所以，他们只用了 3 个月就掌握了一大堆很有价值的技能，而那些花 4 年学习编程后毕业的人，可能掌握了这些技能，也可能没有。这更像是碰运气。Yeah. And there was such a huge demand for software engineers that they got hired as a junior engineer level or almost at an apprentice level, but what they knew uh compared to computer science uh science grads, they knew version control, they knew Git, they knew pull requests, they knew they knew a database, they knew a front end, they knew new Chrome developer tools. So, they actually had a bunch of valuable skills in only 3 months that the people coming out from programming in 4 years might or might not have had. It was more of a toss.

对，没错。比如我算过，读完计算机科学学位所花的小时数，大致相当于平均全职工作 15 个月。呃，而且这还包括所有理论内容，以及那些你知道的、相关性值得商榷的东西。呃，它同样是想把你从毫无经验培养到具备就业能力，无论是走行业路线还是学术路线。你看，这跟一个 6 个月的训练营相比，对吧？差距其实没那么大。尤其是其中一种训练营会把重点放在这些立刻就用得上的东西上；而另一种则是：给你一些内容，希望能教会你如何思考这类问题——或者说得刻薄点，这些东西在我还是学生的时候有用。Yeah, exactly. Like I've done the math, the number of hours in a CS degree is roughly equivalent to like 15 months on average of full-time employment. Uh and that includes all of the theory stuff, all of the things that are you know like questionably relevant. Uh and is similarly trying to take you from no experience to employable in either an industry or academic direction. And like that is compared to a 6-month boot camp, right? Like that's that's not a huge gap. Especially when one of those is laser-focused on these are all things that are just immediately relevant. And one of them is here's some stuff that'll hopefully teach you how to think about these problems maybe or less charitably this was useful when I was a student.

另外，我们能不能提一下，一些最成功的学校其实在美国以外？其中一所——其实很多学校都是这样——当然，大家熟悉的那些名校，比如 MIT、斯坦福等等，都备受推崇。不过，加拿大的滑铁卢大学让我很惊讶：我发现一大批硅谷公司里都有很多滑铁卢大学的毕业生。我就在社交媒体上问：“滑铁卢到底是怎么回事？他们在加拿大呢。为什么大家都从那里招人？”后来我才知道，滑铁卢大学有这样一个项目：他们会教你计算机科学或软件工程，我不太确定具体是哪一个。但最主要的是，他们有专门安排的实习岗位。等到学生毕业时，他们已经在不同的公司实习过四次了。Also, can we just mention some of the most successful schools were actually outside of the US? One of them well, a lot of the schools are of course you know the usual suspects are are very highly regarded from the MITs, the Stanfords and so on. But Waterloo in Canada, I was very surprised to see that all a bunch of Silicon Valley companies have a high number of Waterloo grads. And I asked this on social media, like what's what's up with Waterloo? They're up in Canada. Why is everyone hiring from there? So it turns out that Waterloo has this program where yeah, they teach you computer science or software engineering, I'm not sure which one. But the main part is that every they have dedicated placements. By the time someone graduates, they will have had four placements/internships at different companies.

而且因为他们有人脉，合作对象往往会是 Shopify、Meta 这类公司。所以你会有一位工程师——你知道，三个月乘以四次，就相当于在这些公司里工作了一年。And because they have the relationships, this will often be the Shopifys, the Metas, this. So you will get an engineer who you know 3 months times four, that's like a year working inside of these companies.

是的，这就是价值所在。没错。比如说，你大概可以把那个“三”先放一边——不，不是说真的丢掉，但依我看，这本身更有价值。当然，我不是想贬低理论的重要性。不过从招聘经理的角度来看，他们可能会想：“哦，没错，我会选这个人，因为他能很快上手。哇，他们在不同的环境里工作过，甚至第一天就能给我们带来一些新想法。”Yeah. And that is the value. Yeah, exactly. Like it's it's not you can probably throw away the three not not throw away, but that is more valuable itself if you ask me from a I don't want to downplay the importance of theory by the way. But from a hiring manager point of view, like, oh yeah, I'll I'll take that cuz that person will be up to speed. Wow, they work in different environments. They might even bring some ideas from day one to us.

是啊。我特别羡慕……我觉得不只是滑铁卢大学，加拿大很多学校都是这样，顺便说一句，这只是一个例子。是啊，不过加拿大很多计算机科学专业在实习和合作教育项目方面的课程安排都要强得多，所以很多学位现在要读五年。但我觉得这能带来更好的教育体验，因为有些经验教训——我完全承认，有些东西我们没有纳入软件工程的课程要求，因为在学术环境里根本没法做到，对吧？有些经验你只能真正地去学，比如在工作中学。虽然你刚才举了做项目的例子，我也希望我们能做更多项目，但我真的很担心，大多数学位课程里只有一门项目课。因为你知道，从来没有哪个团队会是由一群背景水平完全相同的人组成的，对吧？Yeah. I'm incredibly jealous of I don't think it's just Waterloo, like a lot of the Canadian schools are just one of example, by the way. Yeah, but uh yeah, a lot of the Canadian uh schools for CS have substantially stronger programs on internships and co-ops in a way that a lot of those degrees run 5 years now, but I think it is a much stronger educational experience because there are some of those lessons, like I will fully admit, like there's stuff we did not put into the software engineering requirements cuz there's just no way to do that in the academic setting, right? There's some lessons you're going to have to learn the real way, like in the field. Even though you gave the example of like doing a project. I want us to do more projects, but I'm really nervous about there being one project course in most degrees because you know what no team has ever looked like? A bunch of people with exactly the same level of background, right?

这也会让人对团队合作究竟是什么产生错误的印象。就，呃，我觉得做了总比不做好，不过，嗯，是的。Like it also gives the wrong taste about this is what teamwork is. Like, uh like I'll take it's better than not doing it, but there yeah.

借助人工智能学习、评估与实践课程设计Learning with AI, assessment, and practical curriculum design

嗯，现状就是这样。希望这个体系能在你这样的人和其他人的推动下，逐渐开始改变，或者说适应时代。不过，AI 现在已经来到我们身边了。一个让经验更丰富的工程师思考的重要问题是：我们是在 AI 出现之前学会构建软件的。我们很多人掌握了不少基础知识，也学过计算机科学，因此在理论上有很扎实的理解，尽管其中有些内容我们可能会用到，也可能用不到。那应届毕业生呢？如今他们进入职场时，能用上的只有我们今天所拥有的这些能力。你觉得他们应该专注于哪些基础知识，又有哪些事情可以直接依赖 AI？大家总会问：这件事该直接问 AI，还是应该先学好基础知识，对吧？Well, we have what we have, and this system will hopefully with people like yourself and others will hopefully start to also change or or just adapt to the times. But, AI is right now here, and one big question more experienced engineers are thinking about, like we've learned to build software pre-AI. We have a bunch of we know the fundamentals of many of us went through computer science, so we actually have a very strong theoretical understanding, which we might or might not use some parts of it. But, what about for new grads? Now that they'll enter workforce of just today with just the capability that we have, what do you think the fundamentals are that they should focus on, and what are the things that were they should just rely on AI? There's always the question of like, should you just ask AI for this or should you learn the basics, right?

是的。所以，我觉得“学习基础知识”这个问题本身就很有争议，因为没人能就基础知识到底是什么达成一致。这也很正常。Kent Beck 几个月前我们上次见面时说过类似这样的话：现在还在工作的人，都是在一个有章可循的时代成长起来的。至少理论上，我们知道正确的做法是什么。而现在已经没有章可循了，对吧？所以，我们多少都习惯了不知道答案，而且我们当然也不知道现在所谓的基础知识究竟是什么。 我觉得初级工程师应该重点关注几件事。第一，要有足够的韧性，不要只是把工单内容复制到 AI 提示词里，然后试图把生成的结果提交上去。对吧？如果你做的就只有这些，那用一个现成的简短脚本就能取代你。这并不能成为你留在团队里的可靠优势。我觉得利用 AI 提升自己、拓宽信息来源非常重要，但不要立刻让它生成你所有的产出。Yeah. So, I mean I think the learn the basics is an entirely loaded question because nobody agrees on what the basics are. And that's fair. Kent Beck said a couple months ago when we were last together, uh something like everyone that's currently working uh has grown up in an era where there was a playbook. Like we know at least in theory the right way to do this. And there's no playbook right now. Right? So, we all get a little comfortable of not knowing the answer and we certainly don't know the answer on what is still the basics. The things that I think that the juniors should be focusing on, one, uh the resilience to avoid just copying your ticket into AI prompts and then trying to check in that result. Right? Like if you're if that is all that you are doing, you can be replaced with a very short off-the-shelf script. Like that is not a defensible advantage for you being on staff. I think it's really important to use AI to better yourself and to widen your inputs, but not to immediately produce all of your outputs.

大约一年前，我在一家智库听到一个我很喜欢的比喻。呃，我们把它叫作“安德鲁之斧”。意思是，如果我拿斧头去砍倒一棵树，我不会说是斧头砍倒了树，而是我砍倒了树。尽管我们有时会把 AI 拟人化，对吧，它依然只是一个工具。1979 年 IBM 的一份培训手册里有句话：计算机永远不会被追责，因此计算机不应该做管理决策。AI 依然不承担责任。AI 实验室不会替我们承担这些东西造成的错误所带来的赔偿责任。所以，对于那些署着你名字的拉取请求，你必须能够站出来负责。我认为，这就要求我们做事严谨得多，不能偷工减料；而这种对细节的关注，真的很难培养。There's a metaphor that I really liked from about a year ago at a think tank. Uh we called it Andrew's Axe. And it's if if I go chop down a tree with an axe, I do not say that it was the axe that chopped down the tree. It's me that chopped down the tree. The AI, as much as we occasionally anthropomorphize it, right, is still a tool. And 1979 IBM training manual, a computer will never be held accountable, therefore a computer should not be making management decisions. The AI is still not accountable. The AI labs are not going to indemnify us for you know the mistakes that these things produce. So, you have to be able to stand up for whatever your name is on for those pull requests. And that requires a lot more rigor and not cutting those corners and like that attention to detail I think is really hard to train.

嗯，回到本科阶段这个话题，我从很多教授那里听到的那个令人担忧的说法是：最优秀的学生——比如成绩在 B、B+ 及以上的学生——比以往任何时候都优秀。Um going back to the sort of the undergraduate version of this, the story the scary story that I've been hearing from a lot of profs is the best students, like the B B+ and above students, they are better than they ever have been.

嗯。因为他们有——对，因为他们不用依赖一位每周只有几个小时能辅导他们、年级比他们高一两级的助教，而是随时都能得到一位耐心无限、随时在线、博览群书、有时还会产生幻觉的辅导老师，对吧？他们随时都能学习、讲解、弄明白……Mhm. Because they have Yeah, because instead of relying on a TA that is available, you know, a couple hours a week and is one or two grades above them, they have an infinitely patient, always available, incredibly well-read, sometimes hallucinatory tutor right at the drop of a hat, right? They can always learn and explain and figure out

他们确实有自主性，也有动力去使用它。对。而且他们还有元认知资源，不会觉得“我就直接复制粘贴好了”，对吧？最差的学生多少也变得好了一点，因为以前他们什么都做不了，但现在至少能产出些垃圾内容。And they actually have the autonomy and the drive to use this. Right. And the and the metacognitive resources to avoid that like I'm just going to copy and paste, right? The very worst students are somewhat better because they used to not be able to do anything, but now they can produce slop.

对，他们就是在胡乱交些垃圾内容，是吧。没错。这有点难发现，不过我懂你的意思。没错。呃，但中间那一大群人基本上都垮掉了。他们没有那种韧性。他们宁愿去派对或者打电子游戏，也不愿做作业。所以他们就会想，嗯，就这一次，我就养成这么做的习惯吧。然后这条滑坡就会越来越陡，对吧？所以有很多还不错的学校里的教授会说，是啊，我也说不好，伙计。我不确定那些处在中间大多数人以下的人——所有成绩低于 B 的人——是不是根本就不懂代码是怎么运作的。系统根本就不是为追踪这类事情而设计的。Yeah, they're just throwing slop, yeah. Right. Which is a bit hard to detect, but I get what Right. Uh but everyone in the middle has kind of collapsed. They don't have that resilience. They would rather go to the party or play video games than do the homework. And so they like, well, just this one time I'll just get in the habit of doing this thing. And that slippery slope just gets worse. Right? And so like there are a lot of profs from decent schools that are like, yeah, I don't know, man. Like I'm not sure that anyone like below like the vast middle, everyone below a B, might not understand how code works at all. Like the system is just not set up to be tracking that sort of thing.

或者至少给他们一些反馈，比如发出提醒之类的，对吧。没错。所以一开始有很多讨论都在说，我们该如何阻止学生使用这些 AI 工具？我觉得这简直荒唐，因为这不过是高阶语言和编译器出现时那种论调的回响。就像……但现在你不会去学用汇编语言编程了，对吧？反正行业里都在用这些工具。Or at least giving them feedback, for example, alerting, those kind of things, yeah. Right. And so a lot of the discourse initially was how do we prevent students from using these AI tools? And I think that's nonsense because it's echoes of like we got high-level languages and there's compilers. Like But now you're not going to learn how to program in assembly, right? Like the industry is using it anyway.

对。他们找工作后会被要求使用——在某些地方，他们甚至会被迫承受压力，更加积极地使用它。嗯，如果那……这可能会……如果一个应届毕业生说“我没用过这些工具”，那肯定是个危险信号。拜托，你难道没有……Right. They're going to be asked to use They're going to be forced to pressure to use it harder in some places when they get a job. Well, if that it might be it will for sure be a red flag if a new grad says like I've not used these tools. Like come on. Have you not

是啊。你是不想在这个行业工作吗？我们在做什么，大家心里都清楚。我们把这些内容发在博客上，到处都在发布。对，没错吧？所以，“我们绝不会让你使用这些工具”这条界线根本不可能守得住。嗯，我这个月和一群学者在《美国计算机学会通讯》上共同发表了一篇文章。嗯，我想开篇第一句是：“想象一下未来的2040年。”呃，假如我们坚持把所有使用 AI 的行为都视为作弊，可有一代学生是在 AI 的陪伴下长大的——你知道，就像互联网原住民伴随着网络成长一样。对吧？如果我们还一直问他们这些传统问题，比如“找出这个字符串中的回文”或者“根据这张图表计算降雨量”，对吧？那他们还能从传统的计算机科学学位课程中学到什么呢？我觉得答案显然是：学不到。所以，如果我们知道不能一直停留在现状，而且还有很多事情需要改进……Yeah. Do you not want to work in this industry? It's an open secret what we're doing. We're publishing it on blogs and everywhere. Yeah, exactly, right? And so the line of well, we're going to never let you use these tools cannot possibly hold. Um I co-published a piece in Communications of ACM with a bunch of academics this month. Um the I think the opening line there is imagine forward to 2040. Uh and we hold the line treating all use of AI as cheating, but a generation of students AI you know, they've grown up with AI in the same way that the internet natives have grown up with the network. Right? If we keep continuing asking them these traditional questions about like find a palindrome in this string or measure the volume of rainfall in this graph, right? Like are they going to learn anything from a traditional CS degree? And I think the answer is obviously no. So like if we know that we cannot stay here and there's plenty of things that need fixing.

比如说，我们不如推倒重来，做点真正有意义的事，再想想该如何恰当地利用它。我觉得，我们可以想办法把他们正在使用 AI 这件事当作前提。那么，新的学习目标是什么？又该如何设计，让学习仍然保留一定的阻力，促使他们思考并学习不同的东西，而且几乎可以肯定，达到更高的层次？对吧？但这实际上正是本科教育、课程设计和评估的关键。Like let's burn it down and do something that matters and figure out how to use this appropriately. And I think finding ways to assume that they're using AI. And what are the new learning objectives? And how do you make that still frictionful in the ways that cause them to think and learn about different things like almost certainly at a higher level. Right? But like that's actually the key to undergraduate education and curriculum design and assessment.

嗯，听起来教授、助教以及设计这些课程的人都得投入大量精力，因为目前还没人把这些问题完全摸索清楚。你们需要不断尝试，首先得亲自使用这些工具。Uh it sounds like whoever's uh so the professors, the TAs, the people who are designing these course, they also need to put a bunch of work because no one has this figured out. You need to experiment. You need to first use these tools yourself.

没错。你得想出一些新颖的方法来设计作业：完成作业时需要用到 AI，但光靠 AI 又不够。怎么获得反馈呢？你可能得多花些时间。比如说，之后坐下来和某个人聊聊，让对方给你解释一下，因为你知道，面试也在变化。而现在看来，一种效果不错的面试方式是和别人结对：可以通过视频，也可以当面；你会用 AI，但同时要解释自己在做什么、怎么做，对吧？因为现在你不能再完全糊弄过去了。你把任务交给朋友，或者干脆让 Claude 来做，这些都行不通。你现在展示的是自己的认知能力。面试官可以把你逼到不太舒服的境地，借此判断你的专业水平，然后不断深入追问，诸如此类。Yep. You need to come up with novel ways of creating an assignment which you need to use AI to solve, but AI itself is not enough. How do you get the feedback? You might need to put in more time. Let's say, like, sit down with someone afterwards and have them explain to you cuz, you know, again, like, interviews are also changing. And one of the interviews that seem to be working well is when you're pairing with someone, you're like, video or in person, you're using AI, but you're explaining what you're doing and how, right? Cuz now you cannot just fully fake it and go away. You give it to a friend or or just have Claude do it. You're you're now showing your cognitive ability. The interviewer can push you into uncomfortable, you know, they'll they'll they'll they'll get a gauge of like how expert you are and push you further and further and so on.

是的，没错。而且在本科阶段，确实有些人开始更多地采用口试之类的方式。但我觉得还有个特别简单的办法：别只给最终结果打分，要关注过程。对吧？比如说，即使你不打算设计难得多的考核作业，也别只给他们提交的代码打分。可以改为评估他们用了哪些提示词才得到这个结果，还要看他们提供了哪些测试。比如，他们是怎么确保这个东西确实能完成所需功能的？当你开始关注得出结果的过程，而不只是结果本身时，我觉得这不仅适用于计算机科学，也适用于大多数领域，对吧？我们一直都在让学生写一篇关于《麦田里的守望者》的新论文。可我们不需要再多一篇关于《麦田里的守望者》的论文了。Yeah, exactly. And at the undergraduate level, like, there is some move towards more oral exams and those sorts of things. But also, I think a really simple solution is stop grading just the outcome. Focus on the process. Right? Like, even if you don't come up with wildly harder assess assignments for assessment, stop grading just the code that they turned in. Grade instead, what are the prompts that you used to get here? Also, what are the tests that you provided? Like, how did you make sure that this thing is actually doing what you need it to do? And like, when you start focusing on like, the process that got you there instead of just the outcome, like, I think not only CS, but most disciplines, right? Like, we've been using go write a new essay on Catcher in the Rye. Like, we don't need another essay on Catcher in the Rye.

去写一个新的链表。我们不需要另一个链表。我们一直把由此产生的成果当作一种替代指标，认为你投入了时间、经历了艰难过程，也遇到了阻力，因此我们假定你已经学到了东西。也许更合适的做法是，专注于我们有没有证据表明你经历了挑战并从中学到了东西？把整套成果都交上来。对吧？课程通常由委员会设计，这自有其道理。但如果你有一所 Titus 软件工程学院，可以亲自为本科课程制定课程体系和学习计划，学制比如三到四年，你会怎么设计？就现在而言，我们讨论的是培养工程师，理想情况下，让他们进入软件和工程公司后能够迅速上手，当然要会使用 AI 工具、开发软件，诸如此类。Go write a new linked list. We don't need another linked list. We've been using the artifact that's produced from that as a proxy for you put in the time and the struggle and like, faced the friction that we assume that you now have learned something. It might be more appropriate to just focus on do we have evidence that you struggled and learned? Turn in the whole package. Right? Curriculums are designed by committees, which is for a good reason, but if if you had Titus's software engineering school where you could yourself put together the curriculum and study course for an undergrad course of let's say 3 to 4 years, how would it look like? Right now. And we're talking about getting engineers ideally having engineers who can hit the ground running at software and engineering companies obviously using AI tools, building software, that kind of stuff.

是的。所以我觉得，第一门课，也就是第一个学期，应该从不借助 AI 开始。我们至少得让你达到这样的水平：能够读懂代码，对代码在做什么有个大致概念，比如能理解控制流程之类的。我觉得，在教育中如何以有充分引导和约束的方式使用 AI，这方面有些非常有意思的做法：我们会有意不直接把答案给你；而且如果评估的是整个学习成果和创作过程，那就不必担心他们跑去问 ChatGPT，直接拿到完整答案，对吧？所以，有些问题已经考虑到了。我的意思是，坦白说，我也不知道。没人知道。根本没有现成的指南，不过……Yeah. So, I think the first course, like the first semester, starts unaided by AI. Like we need to get you through at least the level that you can read code and have a vague idea of what's going on, like can understand control flow and those sorts of things. I think there's some really interesting things on well-scaffolded and harnessed AI for educational purposes of we're intentionally not just going to give you the answer and in conjunction with if you're assessing the whole package and process of creation, then you don't need to worry about them going to chat GPT and just getting the whole answer, right? So, like some of that's covered. I mean, I'll be honest, I don't know. Nobody knows. There is no playbook, but

我想变得更有主见。我想变得更有主见。我……所以，我有个想法：开一门 CS 0 课程，面向非专业和专业学生，呃，介绍编程。具体来说，怎么描述接口的输入、输出、结构和设计？对吧？我们可以聊聊复选框和单选按钮有什么区别，什么时候该用按钮，什么时候该用其他 UI 控件。对于非 UI 的东西，比如命令行标志、位置参数之类的，该怎么把这些组件连接起来？重点是，即使你只上过这一门课，至少你为自己的使用场景用 AI 氛围编程搞出来的那些烂东西，也会有稍微更连贯、更合理的设计语言，而且更符合实际用途。比如说，我住在纽约。呃，我住的公寓楼里有……你知道，洗衣房有个应用。I want to get opinionated. I want to get opinionated. I So, one of the ideas that I've had is let's make CS zero, like non-majors and majors alike, uh intro to programs. Like specifically, how do you describe the inputs and outputs and structure and design of the interfaces? Right? So, we could talk about what's the difference between a checkbox and a radio button. When do you use a button versus some other UI widget? For non-UI things, like what command line flags, you know, positional parameters. How do you like interface these components? Specifically so that if that's the only class that you ever took, at least the AI vibe-coded slop that you produce for your own use cases is going to have a like slightly more coherent, sensible design language and like be more fit for purpose. Like, I live in New York. Uh the condo building I'm in has a, you know, there's an app for the laundry room.

而且这简直让我抓狂，因为他们用的是菜单式 UI，而不是按钮，对吧？而且整个设计语言都完全不对。先从这个讲起。然后再逐步过渡到你刚才说的那些内容：我们想把视野拓展到项目协作、团队合作之类的方面。试着激励他们，让他们自己也想去解决更大的问题。接着，他们就需要了解一些背景知识，比如：“哦，网络是这样运作的。远程 API 的 RPC 调用是这样工作的。”你没法给别人提供问题的解决方案，而他们甚至还没意识到自己有这个问题，对吧？在他们开始尝试解决这些问题之前，我们从理论上讲的那些解决方案都只是些琐碎知识，只是孤立的学术内容，跟任何事情都没有关联。可以先让他们进入一个确实需要这些知识来解决问题的情境中，以此激发他们的兴趣。And drives me insane because like they use like menu UI instead of a button, right? And like the just the design language is completely wrong. Start with that. And then graduate kind of along the lines of what you were saying of like we want to move up into like projects and teamwork and things like that. Try to motivate them into in themselves wanting to solve a bigger problem. And then needing some background on, "Oh, this is how the web works. This is how a web remote API RPC call works." You can't give people a solution to a problem they don't realize they have, right? And until they're trying to solve these problems, those solutions that we present in theory are all just trivia. They're just isolated, academic, not connected to anything. Like motivate that by like getting them into a situation where they need that as the answer first.

然后你就可以提供那些背景信息。我也特别希望能有更多项目，原因有两个。我不希望作业都只有一个正确答案，因为行业里不是这样运作的。研究工作大多也不是这样。还有，我希望他们的评分中有一部分是对他人进行点评。比如看看他们的成果、代码，或者两者都看，对吧？然后能够说：“做得真棒。你有没有想过在这里换一种做法？”同时也要评估他们能不能在不给人难堪的情况下提供反馈。毕竟团队合作需要心理安全感，对吧？所有这些听起来工作量很大，不过你可以用 AI 来帮忙做一部分分析。比如做一下情感分析：这话说得不客气吗？诸如此类。我觉得这样我们就能建立一种更实用、更注重动手实践、也更有效的教育体系。And then you can provide that background. I also desperately want more projects for two reasons. I don't want the assignments to be there is a correct answer because that's not how the industry works. Mostly not how it research works. And I want them to grade Part of your grade is critique of others. Like look at their outcomes or their code or both. Right? And be able to say like, "That was great. Did you think about doing a different thing here?" And then also grade them on can you give feedback without being a jerk? Because psychological safety in teamwork, right? And all of this sounds like a lot of work, except you can use AI to like do some of that analysis. Like let's do the sentiment analysis. Was that rude? Right? Things like that. And like I think we could have a much more practical, hands-on, like and much more effective educational structure.

而且我担心，这会发生在软件工程系，而不是计算机科学系。And I worry that's going to be software engineering departments and not CS departments.

职业建议、领域专业知识与结语反思Career advice, domain expertise, and closing reflections

最后，想请你给现在的毕业生一些建议：那些正在读计算机科学或软件工程专业的大学生，眼看着进入这个行业的竞争越来越激烈，工具也在不断变化。你会建议他们采取哪些做法、策略，或者参与哪些活动，来尽可能提高进入这个行业并在其中取得成功的机会？And as closing for grads right now, college students sitting inside of CS programs, software engineering programs, who are seeing, okay, it's it's more competitive to get into the industry, tools are changing, what advice would you give in terms of tactics, strategies to activities to do to maximize your chances of getting into the industry and then doing well there.

这听起来可能有点冒险，但我人生中大多数成功，都源于我没有去做别人都在做的事。如果你只是追逐热门话题，跟风去做所有人都在做的同一件光鲜事，那真的很难脱颖而出，对吧？所以我觉得，关键是忠于自己，对吧？找一件你真正感兴趣的事，投入时间去做你在乎的事，尤其是当它比你周围的人做的事更古怪时。这样，你就会有一个新颖的故事可以讲给面试官听。在鸡尾酒会上，你也会是个值得交谈的人，这样那位初创公司创始人就会想：“好，我愿意在这个年轻人身上冒个险。”对吧？而且你在这些事情上投入的时间越多，积累的专业知识就越深，最终也会越受益。This might be risky, but most of my success in life has come from not doing the thing that everyone else is doing. Like it is really incredibly hard to stand out if you are just listening to what is a hot topic and chasing the same shiny thing that literally everyone else is doing. Right? And so I think it is to thine own self be true, right? Like find something that you are actually interested in and put in the time doing something that you care about, especially if it's weirder than what everyone else around you is doing. Because then you will have a novel story to tell your interviewer. You will be worth talking to at a cocktail party, so that the, you know, startup founder is like, yeah, I want to take a risk on this kid, right? Like and the more time that you put into these things, the more expertise that you can bring to it, like the better off you're going to be.

我担心，在 AI 辅助工程的时代，我们对扎实工程技能的重视程度正在下降。比如说，你不需要那么深厚的专业功底也能应付过去。但要弥补这一点，你就必须对自己所涉足的问题领域有更深入的理解。我认为，这实际上可能会降低行业内的流动性。也就是说，不再是“我是 C++ 工程师”或“我是后端工程师”，而是“我是嵌入式音频领域的工程师”。对吧？你必须对这些问题领域有更深入的理解，而这才是你真正的优势。I have a worry that with AI-assisted engineering, our emphasis on raw engineering skill is dropping. Like you can get by with a lot less of that depth. But the only way to replace that is you need to understand the problem domain that you're operating into a much deeper level. And I think that might actually lead to less mobility in industry. Like, it's not I'm a C++ engineer or I'm a back-end engineer. It's a I'm an engineer in embedded audio. Right? Like, you have to understand those problem domains to a much deeper level, and that's your actual advantage.

最后收个尾：除了你那本很棒的书之外，你还会推荐哪本书？为什么？我之前提过，不过还是推荐它吧。嗯，Cat Hicks 写的《软件团队心理学》。特别是里面有几章，要是能把它们直接下载到每位领导者的脑子里，我会特别开心。比如“罐中大脑”这个比喻，真的让人挥之不去。所以，这本书真的很不错。As a closing, what's a book that you would recommend then why outside of your excellent book, of course? I mentioned it earlier, but I'll stick with it. Uh Psychology of Software Teams by Cat Hicks. Especially, like, there are a couple chapters in that if I could have that downloaded into the brains of every leader around, I would be so happy. Like, the brains in jars analogy is um haunting. So, that one's a really good one.

好了，Titus，非常感谢你和我进行这次交流。非常感谢你邀请我来。这次聊得特别愉快。我很高兴终于能和 Titus 坐下来聊聊，而这次交流也没有让我失望。首先，我知道 Google 的代码库很庞大，但完全没想到我们说的是仅 C++ 代码就有 2.5 亿行。而且这还是 AI 出现之前的情况，所以我们说的并不是 AI 生成的那些冗长代码库。作为对比，2016 年 Uber 的移动应用代码库大约有 100 万到 200 万行 iOS 和 Android 代码，而 Uber 把大量业务逻辑都塞进了这些应用里。Titus 和团队在不使用 AI 的情况下清理这些基础代码的过程也相当有启发性。他们构建了确定性的代码生成工具来解析代码、匹配模式，然后生成修改。即使在今天，这种方法仍然可能比直接让非确定性的 AI 重构代码库更可靠，尽管要在 Titus 和团队处理的这种规模的代码库上编写高级解析逻辑，无疑要困难得多。Well, Titus, thank you so much for this conversation. Thank you so much for having me. This has been a lot of fun. I'm glad I got to finally sit down with Titus, and this conversation did not disappoint. To start with, I knew that Google's code base was large, but I had no idea we're talking about 250 million lines of just C++ code. And this was all pre-AI, so we're not talking about over the verbose code bases generated by AI. As comparison, Uber's mobile apps had code bases of about 1 to 2 million lines of iOS and Android code back in 2016, and Uber crammed a lot of business logic into those apps. How Titus and the team cleaned up these foundations without using AI was also pretty educational. They built deterministic code generation tools to parse the code, match patterns, then generate edits. This is an approach that still could work more reliably even today than just asking a non-deterministic AI to refactor a code base, even though it is arguably more difficult to write advanced parsing logic on a code base like Titus and team did.

我也很认同 Titus 对于当下 AI 在哪些方面能发挥作用的看法。他提到一位资深工程师说过这样一句话：“我们的代码量增加了 70%，但故障也增加了 30%。功能数量却没有变化。”嗯，这听起来可不太妙。那么 AI 的价值在哪里呢？Titus 认为，如果只是把 AI 之前做过的事做得更快，我们其实得不到多少价值。真正的价值在于更有雄心，去做那些更难、在 AI 出现之前我们根本不会尝试的事情。 最后，我常听到人们担心科技行业的应届毕业生该如何找到工作，尤其是在 AI 智能体已被广泛使用、但计算机科学专业的课程却尚未将其纳入教学的情况下。Titus 是少数参与过计算机科学课程指导委员会的工程师之一。他说，这个专业要么进行大幅改革，让课程更加注重实践，要么计算机科学专业的招生人数就会暴跌。I also appreciated Titus's view on where AI is helpful today. He mentioned this quote he heard from a senior engineer that said, "We are up 70% on the amount of code, but we're also up 30% on outages. The number of features is the same." Well, that doesn't sound all that good. Where's the value from AI then? Titus says that we won't get all that much value from doing the same stuff we did before AI, but faster. The value is to be more ambitious and do harder things that we would never attempted before AI. Finally, I hear a lot of worry for new grads in tech about how they'll get a job or not, especially when AI agents are so commonly used, but CS programs have not incorporated them into their program. Titus is one of the few engineers who has been part of the steering committee for the CS curriculum and says that this program needs to either change substantially and be more practice oriented or CS enrollment will plummet.

Titus 还表示，或许现在是时候开设一门软件工程课程，让学生有更多机会使用这些现代工具来构建软件。我认为我们谁都不知道什么方法会奏效，但让更多业界人士参与更新计算机科学专业的软件工程课程，在我看来是朝着正确方向迈出的一步。请查看节目说明，其中包含与《The Pragmatic Engineer》相关的深度探讨，主题包括谷歌的工程师文化、开发者生产力的衡量，以及 AI 对软件工程的影响。如果你喜欢这期播客，我将非常感谢你为它评分，也欢迎留下评论。非常感谢，我们下期再见。Titus also says that it might make sense to finally have a software engineering curriculum that is focused on students getting far more experience building software with these modern tools. I don't think any of us has an answer to what will work, but having more people from the industry get more involved in refreshing the CS software engineering curriculum sounds like a step in the right direction to me. Check out the show notes for related to the pragmatic engineer deep dives on Google's engineer culture, measuring developer productivity, and the impact of AI in software engineering. If you enjoyed this podcast, I'd greatly appreciate it if you left a rating on it and perhaps a review. Thanks a lot and see you in the next one.