WebAssembly 团队成员：谷歌是我工作过的最糟糕的公司

Katelyn 于 2015 年加入谷歌 V8 团队，是编写 WebAssembly 规范的首批成员。她希望通过自己就职于谷歌的这段经历，帮助更多人认识到工作中的 “毒文化 (toxic cultures)”，以及帮助新员工在谷歌拥有更好的职业生涯。

下文整理自 Katelyn 的自述。

刚加入 V8 团队的前几年我负责维护一个将 .NET 应用程序转换为高效 JavaScript 代码的转译器。与此同时，Emscripten 项目也开始启动了。Emscripten 发展迅速，很快成为了标准，并启发了 WebAssembly 的诞生灵感。当时我很幸运能与 asm.js 的创建者 Alon Zakai 共事，并从他的建议和专业知识中学到了很多东西。这段经历让我很自然地成为了 WebAssembly 团队的一员。

在过去的 20 年里，虽然我一直在与慢性病作斗争，但仍能保持高效率工作，这很大程度上要归功于与我一起工作的同事。但即便如此， 谷歌仍是我工作过的最糟糕的公司 ——它给我带来了脑损伤。如果你发现工作让你难以入睡，让你每天都感到紧张，或者让你不断质疑自己的自我价值，那么我鼓励你去寻找新的工作。

当时 WebAssembly 充满潜力，Mozilla 和谷歌都在努力让 asm.js 成为能让任何应用程序都变成 Web 形式的解决方案，虽然双方克服了大部分技术挑战，但有些问题依然难以解决。这时，WebAssembly 也确定了未来的进程：吸收 asm.js 优势的同时解决缺点，并构建一套可以在现有的 JavaScript 运行时上，通过代码生成、调试和其他基础设施轻松实现的新规范。

我作为最早的一批贡献者，对于能参与编写规范感到非常兴奋。虽然具备 Web 开发经验，但制定规范和 Web 开发不太一样，这是一次独特的挑战。委员会必须同时负责项目经理、布道者和开发者的工作。我们和 JF Bastien, Luke Wagner, Alon Zakai, Ben Titzer 等业界大牛，以及无数的其他贡献者一起努力工作，希望构建一个会被数十亿人使用的框架。

这个雄心勃勃的目标给大家带来了巨大压力。要知道 Web 的历史充斥着糟糕的 API、考虑不周的规范和错综复杂的安全漏洞。一个程序员在一周内完成的工作，可能会在未来数十年消耗开发者的工程时间。WebAssembly 不能也不会以 “半成品” 的状态发布成规范。因为作为浏览器开发者，我们深知每个人要为此付出的代价。

项目的重要性和随之而来的压力，引发了团队的斗争，也毒害了工作环境。大家的讨论变得愈加激烈，两位来自竞争公司的专家经常无法达成一致，每个人都坚持己见。为此，会议主题经常会跑偏，导致浪费了时间且没有任何结果。而在健康的工作环境中，通常会有项目经理和负责人及时发现和解决这些问题，以推进项目发展。

当时 WebAssembly 团队没有项目经理，虽然大家都知道需要这个角色，但最后只有一名志愿担任此职位的临时项目经理。这将复杂的社会和组织挑战留给了过度劳累的工程师，他们几乎没有解决这些问题的经验。最终 WebAssembly 规范的最小化可行产品被推迟发布，项目质量下降，贡献者选择离开 —— 这在开源历史上算不上是独特的故事，但仍然令人不胜唏嘘。

当一个团队缺乏资源，并且领导者缺乏对计划、资源和时间进度的控制时，再小的问题都会酿成大错。这个时候，公司其他部门感兴趣的同事参与了 WebAssembly 项目，希望运用他们的专业知识来 “修复”—— 其实他们只是希望通过这个项目包装自己，进而提升价值。

为此导致的结果是，WebAssembly 规范最终构建在晦涩难懂的技术之上，这使得其他开发者更难参与贡献，同时让委员会的许多成员感到沮丧。虽然最后 WebAssembly 规范以良好的状态正常发布，但团队也为此产生的问题付出了巨大代价。