GMTC北京站9折购票倒计时,部分日程已上线,戳此查看 了解详情
写点什么

忍受不了糟糕的工作氛围,我退出了 Google WebAssembly 团队

核子可乐、闫园园

  • 2022 年 5 月 13 日
  • 本文字数:3762 字

    阅读完需:约 12 分钟

忍受不了糟糕的工作氛围,我退出了 Google WebAssembly 团队

当地时间 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 做出改变,从而改进开发者参与维护的体验。

 

从上面的案例中,我们或许能够体会到,对于一个团队来说,人员的正常流动无可厚非,但如果是团队管理混乱等问题离开,势必会不利于团队的正常、健康运行,甚至会在很大概率上掣肘相关技术的发展。或许,在当下,比起技术实现、创新等难题,更值得大家思考的是如何治理好团队,平衡工作和“人”之间的矛盾,实现团队高效、稳定、可持续的发展。

 

参考链接:

 

https://medium.com/@katelyngadd/why-i-quit-googles-webassembly-team-and-how-it-made-me-sick-c50ef562ce1

2022 年 5 月 13 日 15:291

评论

发布
暂无评论
发现更多内容

《我想进大厂》之JVM夺命连环10问

艾小仙

Java 编程语言 JVM jvm调优

食堂就餐系统UML图

小兵

成为架构师 - 架构师训练营第01周

陈永龙Vincent

我在苦苦坚持的时候,WebStorm已经悄悄的“真香”起来

小Q

Java 学习 架构 面试 webstorm

架构师训练营 -week05- 作业

大刘

极客大学架构师训练营

美滋滋!阿里内部最新出台Java开发规范和系统性能优化指南~

Java架构追梦

Java 学习 架构 面试 性能优化

科大讯飞胡国平:AI和5G互相辅助,认知中台传递基础技术能力

薛梁Lucien

学习 AI 语音识别

区块链:现实与未来的二律背反

CECBC

区块链 虚拟世界

《我想进大厂》之Dubbo普普通通9问

艾小仙

Java dubbo RPC HTTP

架构师训练营第一周总结

小兵

架构师训练营培训第一周作业

lakers

极客大学架构师训练营

架构师训练营第 1 期第 5 周学习总结

好吃不贵

极客大学架构师训练营

架构师训练营第 1 期 week5

张建亮

极客大学架构师训练营

这本书可能是给用户最好的礼物——专栏《软件交付那些事儿》上线

刘华Kenneth

第一周作业1:设计图表

韩儿

架构师训练营 1 期第 5 周:技术选型(一) - 作业

piercebn

极客大学架构师训练营

玩一场用户故事的Cosplay

Bruce Talk

Agile 用户故事 Product Owner

架构师训练营第一周学习总结

韩儿

c++nullptr(空指针常量)、constexpr(常量表达式)

良知犹存

c++

食堂就餐卡系统设计

Jack

架构设计

Week1-架构方法学习

evildracula

学习 架构

一、食堂就餐卡系统UML设计

Geek_28b526

架构训练营第一周学习总结

Jack

前端更应懂产品

执鸢者

产品 腾讯 大前端

Consistent Hash

韩向民

世界上最难的5种编程语言

艾小仙

编程语言 编译 esolang

什么! 你还在使用 if (xxx != null)做NullPointerException判断?

刘超

Java Optional

架构师训练营1期第5周作业--一致性哈希算法

木头发芽

架构师训练营第五周作业

吴传禹

极客大学架构师训练营

架构师训练营第五周总结

吴传禹

极客大学架构师训练营

架构师训练营 - 第一周课后练习

joshuamai

忍受不了糟糕的工作氛围,我退出了 Google WebAssembly 团队_前端_InfoQ精选文章