马斯克称Twitter将专注“硬核软件工程”：要么加班，要么走人

整理 | 凌敏、Tina

据外媒报道，马斯克在当地时间周三凌晨向 Twitter 员工发送一封电子邮件，要求员工在周四下午 5 点之前做出选择——要么接受“极其硬核”的 Twitter 2.0 计划，接受长时间、高强度的工作；要么拿着三个月薪资的遣散费走人。

在这封名为“岔路口”的邮件中，马斯克写道：

展望未来，要想建立一个突破性的 Twitter 2.0，并在竞争日益激烈的世界中取得成功，我们需要“极其硬核”。这也意味着，需要长时间、高强度的工作，只有优异的表现才算及格。 Twitter 将更加以工程为导向。设计和产品管理仍将非常重要，并向我汇报，但那些编写出色代码的人将构成我们团队的大多数，并具有最大的影响力。从本质上来讲，Twitter 是一家软件和服务器公司，所以我认为这是有道理的。 如果你确定你想成为新的 Twitter 的一员，请点击这个链接。 在美国东部时间明天 (周四) 下午 5 点前，任何没有这样做的人都将获得 3 个月的遣散费。无论你做出‍什么决定，都要感谢你为 Twitter 成功所做的努力。

对于这封邮件，网友 Jez Wyke 批评道：马斯克需要具备更好的管理和领导能力，任何需要做的事情，都要给足够的时间和资源，毕竟员工不是你的个人财产。

马斯克的“硬核软件工程”愿景

这并不是马斯克第一次强调“硬核”。早在今年 5 月份，他就曾在 Twitter 上表示，一旦他成功收购 Twitter，公司就将超级专注于“硬核软件工程”、设计、信息安全和服务器硬件。当时“UML 之父”Grady Booch 还曾质问马斯克，“硬核软件工程”究竟是什么意思。Grady Booch 是 IBM Rational 的首席科学家，其在软件架构、软件工程和软件建模方面有杰出贡献，并在国际上享有盛名。

在讨论马斯克的“硬核软件工程”之前，或许应该先聊聊什么是软件工程。

现在的软件开发早已告别了单兵作战的时代，一些中大型软件都是团队的集体智慧产出。而软件工程则是团队协作的基石，区别于传统的项目管理，软件工程是一项复杂的知识工程。比如现代软件开发都建立在 Apache 和 Linux 基金会的众多开源项目之上，成千上万的软件工程师通过集体协作，编写了上亿行代码，最终才诞生了这些伟大的项目。大批程序员通过精细化分工协作，达到高效的工作和高质量产出。

作为软件工程实践最成功的公司之一，谷歌内部曾有声音认为“软件工程是随着时间的推移而集成的编程”。不过，时间对程序的影响是一个没有固定答案的问题，代码的预期寿命无论是几分钟，还是数十年，都能找到合理的解释。对于一个假定只有 1 小时寿命的程序来说，开发者不太可能需要适应新版本的底层库、操作系统、硬件或语言版本。因此，这个短寿的程序实际上只是一个编程问题。如果开发者想延长程序的寿命，就需要对程序做出改变。在十年或更长的时间里，大多数程序的依赖关系，无论是隐式的还是显式的，都可能会发生变化。就需要做出的决策的复杂性及其风险而言，软件工程与编程不同，进一步来说，编程只是软件工程的重要组成部分。

正如 Jorge Luis Borges 所说：没有什么是建立在石头上的。一切都建立在沙子上，但我们必须把沙子当作石头来建造。

在现代软件工程的基础上，马斯克加了“硬核”二字，让一切都变了味儿。

从马斯克的各种言论里，可以推测他所认为的“硬核软件工程”，在某种程度上等同于长时间、高强度的工作。毕竟在接手 Twitter 后，马斯克不止一次强调工时问题。

据 CNBC 11 月初报道，在没有明确加班费的情况下，马斯克要求 Twitter 的部分员工“997”，即每周工作 7 天，每天工作 12 小时。11 月 9 日，马斯克又向全体 Twitter 员工发送电子邮件，要求员工停止远程办公，每周在岗时间至少 40 小时。

马斯克曾在一条推文回复中强调，他对员工职业道德的期望是极端的，但相比对自己的要求来说，还是低了很多。他在前几天举行的第 29 届年度巴伦投资大会上称，收购 Twitter 后，自己的工作时长从每周 70-80 小时增加到 120 小时（平均每天 17 个小时以上）。他在另一场采访中更是强调，“我尽我所能工作——从早到晚，一周 7 天。”

一位程序员网友对此评论说：“我从事过高压项目，如果要从所有这些项目中吸取一个教训，那就是在编码方面，更长的工作时间会导致负生产力，因为你必须在后面进行更多测试、修复更多（最初未检测到的）错误。在我看来，管理层也有责任确保你的员工保持理智和健康——显然马斯克不这么认为。”

Twitter 的软件是不断迭代出来的

从 2006 年建立到现在，Twitter 历经多轮技术迭代，解决过无数类似“失败之鲸”的故障，从而让系统变得庞大而稳固，在此同时，软件工程的复杂性也在不断增加。

在创办初期，Twitter 的架构非常简单，当时创始人 Jack Dorsey 考虑过用 Python、C 和 OCaml 编写软件。不过机缘巧合，他找到了 Ruby on Rails 的核心贡献者 Florian Weber，所以 Twitter 选择了用 RoR 实现。

随着 Twitter 用户规模不断增长，其 Ruby on Rails 部署规模已经是世界第一，最多时机器达到 3000 台。但所有逻辑都在 Monorail 中，当时有超过 200 名工程师往里面 check in 代码，导致系统效率低下，延迟长，难以加入新功能。

随后，Twitter 开始对系统进行拆分，并用 Scala 重写了服务器。经过进一步分解，Monorail 逐渐被分离出来，整个系统从 Ruby 平台迁移到 JVM 上。单机 QPS 处理能力从 200~300 提高到 10000~20000，延迟减小到 1/3；减少了 90% 资源使用。

在经历了多轮系统拆分后，2015 年，Twitter 已经搭建起完整的工程生态，软件工程的复杂度跟十年前已经不可同日而语。

像 Twitter 这样的规模少有其他公司能够达到。在达到这样的规模之前，必然经历过艰辛的拓荒之路，背后更是无数“技术天才”不断地钻研和付出。

知名开发者 Dan Luu 发帖称，Twitter 在基础设施方面，做了非常多的“硬核”工作，而在较为年轻的企业中，这些工作大多会以“云”或开源项目的形式被外包出去。他举例称，很多人可能不知道，Twitter 公司也有自己的内核团队，在设计低功耗服务器时，Twitter 的团队能让服务器达到让英特尔都惊讶的功率范围；在 gRPC 出现之前，Twitter 就开始研究 RPC 了，所以他们构建了 Finagle；Twitter 的内部数据库 Manhattan 的延迟非常低，导致 Twitter 尝试迁移到云并切换到某些云数据库时还曾因此出现问题....

在马斯克接手后，Twitter 的软件工程重心或将再次进行转移，毕竟他理解的软件工程，貌似和大家理解的不是一回事儿。而这些人才也不被珍惜地“清理”了出去。

本周早些时候，马斯克还质疑 Twitter App 在渲染主页时间线时，会执行 1000 多个性能低下的批量 RPC，导致运行速度过慢。对于这个说法，Twitter 软件工程师 Eric Frohnhoefer 站了出来，押上自己的职业生涯跟马斯克正面对决：“我参与 Android 版 Twitter 的开发有大概 6 年了，我敢说这种论断是错的。”很快，Eric Frohnhoefer 就遭到了解雇，一些站队 Eric Frohnhoefer 的工程师如首席软件工程师 Yao Yue、软件工程师 Sasha Solomon 和后端工程师 Nick Morgan 也纷纷被解雇。

对于这些因意见不合而被解雇的工程师们，马斯克还阴阳怪气道：“我为解雇这些天才而道歉。他们的巨大才能无疑将在其他地方发挥巨大作用。”

参考链接：

https://www.washingtonpost.com/technology/2022/11/16/musk-twitter-email-ultimatum-termination/

https://twitter.com/elonmusk/status/1522595770288906242

https://www.infoq.cn/article/twitter-architecture-evolution