硅谷“网红”技术大牛：退休后面试工程主管，他们居然让我写点代码

Steve Yegge 的职业生涯从 1992 年开始，曾先后任职于亚马逊、谷歌、Grab 等企业。他因写有关编程语言、生产力和软件文化的技术博客而受到广泛关注，一些程序员——包括 Python Web Development with Django 的合著者 Paul Bissex——将 Steve 的博客描述为“必读”。

其中关于招聘和面试的一系列帖子，因为辛辣调侃和特别的文风，尤其受到关注。

2011 年，在谷歌任职时，Steve 写了一篇 3,700 字的评论，在文章中点评了亚马逊和谷歌两家的企业文化，并说道“亚马逊每件事都做错了，而谷歌每件事都做对了”。当时他本来想在 Google+ 上和谷歌的员工进行内部讨论，结果不小心把圈子设成了 Public，这篇吐槽文章就公开给了所有人，Steve 也因此在全球爆红。

2018 年，在谷歌工作十三年后，Steve Yegge 决定离开谷歌。至于离职原因，他写了一个更长的帖子，表示“因为谷歌已经失去创新的能力了！”然后事情就再次失去控制了：

至今我依然不能完全肯定，当初那篇“我为何从谷歌离职”博客文章怎么就引起了那么大的关注。基本上我只是表达了“我就是一个喜欢频繁换工作的普通人……”之类的观点，差不多就这意思。可就这么一篇文章被翻译成了大概 80 种语言，甚至变得比 Natalie Portman 的两性专栏更火，老实说，她的专栏内容可有趣多了。

最近，Steve Yegge 又换了一次工作，结束了短暂的退休生活，入职 Sourcegraph 担任工程主管。

这次他在 Sourcegraph 官方博客给大家分享了一些关于代码智能平台的价值观点，经 Steve 授权，我们将他的文章翻译了出来分享给大家。

每过十年左右，在编译器领域都会发生一次大型技术变革。

上世纪九十年代的变革发生在 Borland，它们曾经在编程语言工具领域拥有传奇式的创新，包括 Turbo C、Borland C++ 和 Turbo Pascal 等等。那一场创新浪潮一直持续到 21 世纪初并转移到微软；与此同时，Borland 的编译器团队却面临着被资本无情摧毁的困局，最后也难逃落寞。

微软此后也在编程语言工具领域发起了一轮传奇式的辉煌创新，包括今天我们所能看到的 CLR、C#/.NET、Visual Studio、VS Code 以及其它许多惊艳的产品。

你看，编译器圈子为形形色色的开发者工具创造了代码智能作为底层能力支撑，当这些编译器极客们每过几年一起聚在一块时，就说明影响全世界开发者的变革即将发生。

到 21 世纪初，这场变革开始向谷歌转移。

这正是我曾经工作的地方，和微软在同一条街上的谷歌柯克兰 (Kirkland) 办公室。当微软的开发者在谷歌工作的时候，他们会因为缺乏合适的工具而大发雷霆。尽管所有关于构建、开发和部署的要素都齐全，但是他们无法自如地探索和浏览谷歌的代码仓库，让人感觉一切都是对他们隐形的。

2008 年，我终于受够了他们准确但老实说很伤人的抱怨。我决定构建一个强大的代码智能平台，并取名为 Grok。这个平台可以从生产环境的编译器中获取代码智能信息并聚合为可查询的知识图谱，然后再以 API 的形式将这些智能信息提供给其它工具。这是一种可以帮助所有工具让你更轻松地浏览代码的方法。

Grok 本身并不是一个产品；它只是一个为其它产品提供底层能力的引擎。

Grok 在谷歌获得了持续性的成功，为编辑器、批处理自动化工具、代码审查工作流、搜索引擎、代码浏览器、IDE、命令行、代码查询引擎、Notebooks 以及其它许多临时和定制工具提供代码智能。

Google Code Search 当属由 Grok 赋能过的最为强大的工具了，我猜你肯定已经从任何曾经在谷歌写代码的人那里听说过它了。

即使站在 2022 年的今天的角度来看，Grok 和代码搜索这对黄金组合所创建的事物也是前所未有的。代码搜索团队在谷歌的可复用搜索基础架构上构建出了谷歌规模的代码搜索。即便没有精确的代码智能，代码搜索自身也是一款非常硬核的产品。

Grok 的作用当然是提供了世界一流的代码智能，使得代码搜索可以提高产品的精确度、准确性乃至整体的可信度。

就开发者工具而言，信任就是一切。所有的编程语言工具和 IDE 已经在准确性和精确度上设定了非常高的标准。

谷歌代码搜索对用户而言就像黑客帝国 (The Matrix) 一样 ，它在谷歌内部调研中获得了近乎完美的满意度，几乎每个离开谷歌的开发者都会想念它。

今天，谷歌的工程师可以比其它任何具有同等量级环境的开发团队能更好地探索和理解数以亿计的代码库。

你会理所当然的认为有人应该已经帮谷歌以外的我们实现了同等功能。

长话短说，在谷歌之外已经出现过对代码搜索的尝试，可以达到谷歌代码搜索被 Grok 赋能之前的不错水平。但距离 Grok 的诞生已经 14 年过去了，依旧没有人能够在谷歌之外真正地完成这项工作。

实不相瞒，我也曾想过自己来担起这份重任；遗憾的是，谷歌并不愿为此花钱。至此，这个项目就进入了搁置期，而我又被云计算、广告业务、游戏业务等等其它事情分去了精力。

我就不相信不可能没有别人愿意去做这件事！是吧？

其实在那以后已经有许多关于代码智能方面的创新了，包括微软、JetBrains 等等。可惜就是没有人做出能够和 Grok 与之媲美的东西。诚然，即使在谷歌这样具备世界一流的调度基础设施的加持、单一构建系统、少量编程语言和单个大仓的情况下也已经难如登天。

这世界上不会再有比谷歌更加同构的环境，却还是让 Grok 险些难产。何谈在谷歌之外创建另一个 Grok？如何支持异构的企业级代码部署环境？可以说是指数级的难度暴增，必须要海量的金钱、人力投入与资源协调才存在一丝可能。

结果就是我们的行业充斥着大量平庸的工具。大多数非 IDE 类型的工具都采用了启发式（或者叫错误的）智能而不是编译器级别的精准智能。这意味着开发者会在使用它们的过程中遇到数以千计的不爽之处，拖累了开发者的生产力。

有一点很清楚：我们唯一能够见证代码智能复兴的时机是全世界的编译器从业者能够自由地聚集在一起。

这就很烧钱了。

代码智能平台之路异常艰辛。整整十年，也许更久吧，我已经对其他人的尝试感到绝望。不过我仍希望有一天我可以重拾旧梦。

几个月前，Sourcegraph 两位创始人 Quinn 和 Beyang 联系了我，看看是否适合担任 Sourcegraph 工程团队的负责人。

某些程度上讲，Sourcegraph 颇受谷歌内部的代码搜索工具（Google Code Search）所启发，Beyang 此前撰文写过谷歌工作时的故事。从一个局外人视角，我一直很欣赏 Sourcegraph。他们一直以来都在尝试做一些与我想法非常契合的事情。

Sourcegraph 主要关注在代码搜索部分（而我在谷歌时没做这块），而且很明显，Sourcegraph 也一直想做更多的代码智能（Code Intelligence）的工作，但代码搜索本身就是一个极具挑战的工程难题。

去年（2021 年），某个创业公司的董事会成员问我，为什么他们公司不能用 Sourcegraph 作为源码分析工具？我深入调研了下，留意到 Sourcegraph 在使用 LSIF 索引方案。LSIF 在 Sourcegraph 的使用场景下凑合着能用；但 LSIF 本身是一种有损的格式，作为代码智能平台的索引数据选型方案而言不太够格。

如果接下来要我搞 LSIF，那我跟 Sourcegraph 缘分就到此为止了。但我决定还是继续看下情况，因为 Sourcegraph 的营收和企业客户付费在过去两年着实开始爆发。

我跟他们的团队成员聊了很多次，然后了解到更多他们的开放式公司文化。这是一个完全远程、重度异步协同的公司，在疫情下简直是初创公司的经典样板。我开始更多地了解他们的产品，这几年来 Sourcegraph 的产品不断在发展成熟。

这一切都非常有趣，但并没有到比其他公司更值得我去选的份儿上。

但随后一个出乎意料的事情出现了：他们让我写点代码。

这是过去 12 个月（我接触了 20 多家公司）的领导力面试环节中，第一次有人让我写点代码。他们希望我写点代码来修复个 Sourcegraph 的 Bug、或添加个功能，或者实现点其他什么的。至于具体我写什么代码，这都不重要。

所以我就去写代码了。我接受了这个挑战，然后写了点代码。

亲爱的朋友们，这就是为什么我选择加入了 Sourcegraph。

因为当我在做这个编码作业时，我发现了两件非常了不得的事情。首先，我发现在跨多个源码仓库的场景下，Sourcegraph 是浏览并理解跨库源码的最佳工具。我当时希望尽快搞定面试编码作业，这意味着我要尽快理解 Sourcegraph 自身的代码。我手头有各种各样的工具：Emacs、命令行、GoLand、VS Code、GitHub，我可以任选它们来完成这个作业。然后我发现当我在尝试梳理 Sourcegraph 前后端逻辑及其他代码时，我用 Sourcegraph 来辅助我的时间比其他工具加起来还多 50%。我并没有刻意为之，用 Sourcegraph 只是恰好是最趁手的方式。 

我还发现了点别的：Sourcegraph 自己搞了个 Grok。这项工作是秘密进行的。准确来讲是一个公开的秘密，毕竟 Sourcegraph 源码都是开源可见的。但这年头搜代码也不容易，呵呵。

但这甚至对公司的许多其他人而言也是个秘密！或者至少，它的重要意义和改变世界的潜力被很多杂事掩盖住了。这可以理解，真的。毕竟大家事儿都不少。就像我刚说的，Sourcegraph 眼下是个工业级的跨仓库的代码搜索及浏览工具，做到这点需要大量的投入。

当这一切都在进行时，Sourcegraph 后端工程师的一小撮群体，在难得的空闲时间里，不知怎么地将代码智能从原型方案一路打磨到企业级可用（仿佛把魔戒从霍比特人村子千里迢迢爬山涉水带到了末日山），与此同时他们一边还要应对代码搜索功能在不断扩展的规模下的技术挑战。这群编译器极客小分队创造了 SCIP — 代码智能协议（the Source Code Intelligence Protocol）。一个不大不小的玩意，你想要注意到它犹如大海捞针。

但在我与他们的技术面试的编码马拉松中，我注意到了 Sourcegraph 底层实现上发生的变化：这是一场革命！这些人正在悄无声息地把 LSIF 替换成 SCIP，作为 Sourcegraph 新的底层架构。

Sourcegraph 的 SCIP 代表着 Grok 的王者归来。它是基于启发式搜索的代码智能实现，它的结构范式定义能为开发者效率实现上千倍的效能提升。它在 Sourcegraph 里潜伏了几个月了。但在被实际使用之前，SCIP 总是被转换回 LSIF 格式！这就是为什么说 SCIP 是仿佛不存在一般。

因此，具有讽刺意味的是，他们打造的这个令人难以置信的代码智能引擎，有着喷气式飞机发动机的性能，却被调成拖拉机档位在工作。

但它就在那儿。在 SCIP 的基础上进行扩展开发是相对容易的，因为你只需让索引工具收集更多信息即可。Grok 和 SCIP 背后的设计理念是它们是可扩展的。你可以不断地将来自社区、工业界和学术界的智能化数据进行建模。一旦有数据开始产生，SCIP 的广泛采用将势不可挡。

Sourcegraph 正在建立一个代码智能平台！想象一下我的震惊。了解我的人都知道，这对我来说是一个多么不可思议的匹配。这就是我未曾完成的事业！很高兴地告诉大家，我作为工程团队的负责人加入了 Sourcegraph，并将一起把 Sourcegraph 带到新高度。我们将很快推出 Sourcegraph 代码智能平台。

还记得 Borland 风头正盛的时候吗？那时候 80% 世界上最好的编译器作者齐聚一堂推动了一场 IDE 工具的复兴。然后它在微软又一次发生了，并且规模大得多，仅仅在 Borland 岁月的 10-15 年之后。

如今，15 年又过去了，我们又要开始引领这场变革了。编译器社区是一个非常小的圈子，大家彼此都很熟，我们将邀请所有的编程语言、静态分析、构建系统、代码托管和开发工具生态的社区伙伴们一起共建。SCIP 是一种互通的格式。它提供了一条让我们彼此共识、且一同进步的路径。它将带来开发者工具的巨大变局。