当地时间 5 月 11 日，游戏设计师、工具开发者 Katelyn Gadd 在一篇博文中分享了她在 Google WebAssembly 团队中的工作经历。这位女士讲述了自己在 Google 任职期间因为管理混乱患上脑损伤并长期饱受折磨，这些负面经历凸显了 Google 糟糕的工作氛围：团队缺乏支持并且领导者们又没有改革能力。“我希望这个故事能够帮助人们认识到自己工作场所中的有害文化，或者能帮助新员工在 Google 获得更好的职业生涯。”Gadd 说。
下面，让我们从 Gadd 的自述中了解事情的原委。
Gadd 的自述
在 Google，我饱受脑损伤的折磨
我是 2015 年初加入 Google 的，当时是作为 WebAssembly 规范的首批作者隶属于 V8 团队。我写这篇文章，是想带大家一起回顾我当初经历的问题、分析这一切给我造成的深切伤害。通过这个故事，希望大家能发现工作环境中的种种有害文化，也希望能帮助新人们在 Google 谋求更好的发展。首先得承认，WebAssembly 项目的历史相当复杂，所以任何回忆都多少会掺杂偏见，我自己也不例外。总之，我会尽量为大家还原出当时的真相。
刚加入 V8 团队时，我的工作就是维护一款转译器——它能把 .NET 应用程序转换为高效 JavaScript 代码。就在当时，Emscripten 也在同时起步，而且很快发展成客观标准，甚至成了 WebAssembly 的开发灵感。我有幸跟 asm.js 的缔造者 Alon Zakai 一起工作，也从他的建议和专业知识中学到了很多。正是初期的美好经历，让我天真地以为自己能继续在 WebAssembly 团队里如鱼得水。
过去二十年来，我饱受各种慢性病的折磨，好在同事们对我体贴有加，才让我勉强坚持下来。这里先给结论：Google 是我待过的最差的企业，而且这份工作经历给我的大脑造成了永久损伤。如果大家在某份工作上辗转难眠，每天感觉紧张焦虑，或者不断质疑自我价值，那我劝大家赶紧换个新去处。
WebAssembly 的雄心令人倍感压力
WebAssembly 确实充满潜力，Mozilla 和 Google 争着想让 asm.js 成为能让任何应用程序都变成 Web 形式的解决方案。凭借强大的技术实力，双方已经攻克了大部分现实挑战，只留下一小部分确实很难解决的问题。到这里，WebAssembly 的改进流程已经基本定型：汲取 asm.js 优势的同时克服其弱点，再构建起一套能在现有 JavaScript 运行时上通过代码生成、调试和其他基础设施轻松实现的新规范。
能成为最早一批规范制定者，这种感觉当然让人兴奋。虽然我有 Web 平台的开发经验，但制定规范还是不太一样，需要面对种种前所未有的挑战。整个委员会既要当项目经理，又要当布道师，同时还得肩负开发任务。我们与 JF Bastien、Luke Wagner、Alon Zakai、Ben Titzer 等业界大牛一道，希望最终构建起一套可供数十亿人使用的里程碑式框架。
但这样的雄心也让大家倍感压力。Web 发展史上充斥着数不胜数的糟糕 API、漏洞百出的规范和错综复杂的安全漏洞。一位程序员花一个礼拜匆匆赶出的成果，也许会在未来几十年里折磨无数开发人员。所以，我们绝对不能让 WebAssembly 成为那种半成品式的粗糙规范，毕竟作为曾经的浏览器开发者，我们都知道一时不慎会造成何等惨重的代价。
团队管理一片混乱：这就是 Google 的工作氛围
这份压力和项目的重要意义，如同毒素般污染着整个团队。大家开始以愈发激烈的态度参与讨论，来自竞争企业的双方专家无法达成一致，每个人都坚持认为只有自己是正确的。会议经常脱轨，一个小时过去却没有任何实质性的进展。在健康的环境中，应该会有项目经理和团队负责人及时发现并解决这些问题，引导工作重新回归正轨。
但当时的我们没有项目经理。虽然我们都知道设立这个角色很有必要，也做过尝试，但最终得到的只是一名临时志愿者。于是乎，复杂的沟通任务和立场性难题就被直接摆在了工程师们面前，这正好是技术人们最不擅长的工作。情况最终朝着最糟糕的方向前进——规范 MVP（最小化可行产品）未能如期发布，项目质量持续走低，贡献者团队也只得分崩离析。这种故事在开源历史上并不少见，但回想起来总是令人不禁唏嘘。
更糟糕的是，团队领导者们因为劳累过度而失去了推动变革的能力。领导应该是整个团队的指路人，而领导力的贯彻又离不开群众的坚定支持。很遗憾，我们的团队领导者没能得到良好支持，整个 V8 团队当时是在向 Chrome 的负责人汇报，而那家伙当时是全公司支持率最低的负责人。纵观整个职业生涯，团队经理被气哭的场景其实并不多见，而 Google 这边就是其中之一。上峰甚至直接质问 V8 主管是不是懦夫、没种，这就是 Google 的工作氛围。
当团队缺少支持，领导者又无权调整计划、资源和时间表，那再小的问题都会演变成大麻烦。意识到进度不畅，Google 其他部门的同事志愿加入进来，想通过自己的专业知识“修复 bug ”——当然，他们也可能是想显摆一下自己的能力，给未来的职业生涯攒点本钱。无论如何，WebAssembly 规范最终集合了众多晦涩难懂的技术元素，导致人们很难做出贡献，也让委员会里的众多成员倍感沮丧。所以虽然规范最后还是正常发布了，但我们一直想努力避免的代价还是成为了现实。
一切有害文化都源自糟糕的行政领导
文章开头，我提到 WebAssembly 这段工作经历给我造成了脑损伤。不开玩笑，这是真的。我在 Google 那两年一直在高强度工作，有时候顶替一下临时项目经理、有时候协助组织会议和记录决策，有时候还得跟充满敌意的同事交流意见。好在团队里大家至少都是想解决问题，所以项目还算维持得下去，但后果还是降临在我身上。慢慢的，我发现自己记性越来越差，有时候在车库里逛半天才想起是要开车出门，甚至会在聊天当中直接断片。为了正常生活，我只能把事情一件件记下来。最终，医生强迫我休一段病假，同时把烟戒掉。刚开始我没当回事，但后来还是接受了建议。
在项目接近尾声时，我决定再做最后一番努力——约一位高管再开个会。这其实不是什么好主意，但我们当时真的没有发表意见的渠道，所以绝望之下只能铤而走险。结果证明，这主意确实不好。
我初入职场是在 2007 年初，当时的工作是在一家游戏工作室担任游戏设计师。在此期间，我很快就明白了自己接下来该往哪个方向发展：当个工具开发者。我一直专注于帮助其他人完成任务，也很能理解他们的压力在哪，遇到了怎样的障碍。这类职能往往吃力不讨好，但对软件开发项目却又非常重要，所以很庆幸当时的同事和领导都能认同我的价值、支持我的决定。在离职之前，我跟那家工作室仅存的最后一位创始人促膝而谈，向他解释了造成项目进度落后、团队压力过大、工作质量低下的原因。我讲了自己的想法，希望能用可操作的方案解决问题并节约资金。但创始人无动于衷，表示不会做任何改变。相反，他打算对团队撒谎，用欺骗的方式诱导大家继续卖力干活……这套路还真是永不过时。
结合个人经历，我发现工作环境中的一切有害文化都源自糟糕的行政领导，Google 也不例外。我也曾向一位 Google 高管解释过 WebAssembly 项目陷入困境的原因，包括团队成员们如何在缺少支持的绝望下选择离开。他同意我的观点，但表示不会做任何改变。最后，还是团队在孤立无援下全靠自己拼出了一条生路。
就这样，我平静地结束了自己的 Google 任职期。休完病假回来后，我发现 WebAssembly 团队基本上已经土崩瓦解了——很多成员转到公司的其他部门。新任经理告诉我，我现在要跟一帮没见过的人一起研究 Chrome 浏览器中一个我根本不熟悉的功能。那没什么好说的，我马上提出离职，并在简单的面谈后拂袖而去。离职那天，我突然发现再过一周就是期权发放日，亏了亏了。之后几年，我完全没找工作，而是根据医嘱努力恢复健康。当然，我偶尔也会写写代码。现在我终于有所好转，也开始从开源贡献中赚取报酬。但无论如何，我再也不是当初那个健康活泼的我了。
希望我的这份避坑指南能给大家一点启示，也祝愿各位能够勇猛精进，探索出适合自己的职业道路。加油！
比技术更难的是“人”的管理
Gadd 的博文发出后，引发了诸多讨论，其中在 Hacker News 相关帖子下就有网友表示“正在经历差不多的情况”。
过度劳累、人手不足、无休止的开会......不得不说，这些团队管理混乱的情况并非个例。早在 2019 年，一位名为 Michael Stapelberg 的 Debian 包维护者就在其个人博客发表了一篇长文，宣布将逐渐减少参与 Debian 的维护和相关活动。
Stapelberg 解释他在 Debian 上投入了十年以上的时间，但在此过程中，也发现了团队的很多问题。首先，他认为 Debian 整个开发评估流程都非常迟钝。举例来说，补丁的评估没有截至日期，有时候他会收到通知说几年前递交的补丁现在合并了。另外 Debian 会给予维护者过高的个人自由度，而一些维护者出于个人喜好拒绝合作，也对 Debian 构成了严重影响。
Stapelberg 抱怨了 Debian 糟糕的开发工作流程，对此感到十分不满，为此，他撰写了长文，并希望自己的文章能激励 Debian 做出改变，从而改进开发者参与维护的体验。
从上面的案例中，我们或许能够体会到，对于一个团队来说，人员的正常流动无可厚非，但如果是团队管理混乱等问题离开，势必会不利于团队的正常、健康运行，甚至会在很大概率上掣肘相关技术的发展。或许，在当下，比起技术实现、创新等难题，更值得大家思考的是如何治理好团队，平衡工作和“人”之间的矛盾，实现团队高效、稳定、可持续的发展。
参考链接：
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论