为什么工程师在编程语言方面无法保持理性

分类佳文共赏
作者Steve Francia
来源跳转
发表时间

内容

领导者的盲点:身份如何驱动数百万美元的技术债务

编程语言是公司做出的最昂贵的选择,但我们却把它当作一个技术辩论。经过观察了几十家公司因这种错误而破产,以及几百家公司受损,我学到了一个令人不舒服的真相:这些决定很少是关于技术的。它们是关于身份、情感和自尊,并且以一种你无法预见的方式摧毁了你的速度和预算。

在我的职业生涯早期,我在一个叫 Takkle 的社交网络公司工作。突然离开后,我从首席工程师变成了工程副总裁,领导一个 12 人的团队。虽然我们在实现所有目标,但我当时只有 20 出头,缺乏经验,这是我们的董事会想要解决的风险。他们向我们的 CEO 施压,要求招募一位具有更多经验的 CTO。他是 Perl 社区中一位知名人物,带着一堆 O'Reilly 的 "骆驼" 书籍来到我们公司。

他采取的第一项行动是宣布我们的语言 PHP 是错误的选择。他下令切换到 Perl。这一决定是在我看来像是一场假分析,比较了 PHP 和 Perl。

我们的速度崩溃了。我们的团队不仅要学习一种新语言,还要从头开始重建,这使我们的产品延迟了 9 个月。我们的每月烧钱率从 20 万美元跳跃到 50 万美元,因为我们增加了团队规模,以弥补失去的速度,同时构建新的基于 Perl 的系统,这使我们的跑道缩短了一半。

我们的 CTO 确实实现了一些他的承诺。我们构建了一个漂亮的系统,我为之感到骄傲。但是为时已晚。到我们终于推出产品时,市场机会已经消失。Facebook 已经扩展到大学以外,我们已经到了我们的财务跑道的尽头。增加的支出使我们的跑道缩短了一半,我们没有足够的动力来达到提高更多资金所需的里程碑。

我常常想:如果我们坚持使用 PHP 呢?我们有一个不错的系统和真正的动力。我们本可以早早推出产品,并且只需花费很小的一部分成本。PHP 对 Facebook 来说已经足够;为什么对我们来说不够呢?

但一直困扰我的问题是:为什么这样一位经验丰富的领导者会犯下如此糟糕的错误

承诺

  • 切换到 Perl 将解锁我们需要的架构
  • 从头开始重建将加速招聘和质量

现实

  • 速度崩溃,因为团队重新学习和重建一切
  • 每月烧钱率从 20 万美元跳跃到 50 万美元

模式重复

随着我的职业生涯的进展,我一次又一次地看到这种模式。在 Google 的语言产品负责人期间,我的团队包括 C++、Java、Go 和 Python。在 MongoDB,我管理着使用 13 种不同语言的团队。在这两个地方,我都看到优秀的工程师们相互争论,拿着相互矛盾的数据,所有这些数据都是真的,但没有一个是完整的。在 Google Cloud,我在我们的客户中看到了相同的挑战。

快进 20 年,从 Takkle 开始,我经历了一次似曾相识的经历。我看着一位工程副总裁向领导层展示为什么他的团队需要使用 Rust 构建他们的下一个系统。演讲内容与我在 Takkle 的经历惊人地相似。在旧演讲中,CTO 提出的每一个理由都是当时 PHP 的优点。现在,每一个理由都指出 Rust 是更好的选择,例如 "易于构建和部署"。虽然这确实是 Rust 的一个优势,但 Go 的几乎瞬间的跨编译和单个静态二进制文件在这个特定标准中甚至比 Rust 更强大,Rust 的构建时间非常长。

我并不是认为他们应该选择 Go,Go 对他们的情况来说是错误的选择,我相信 Rust 是正确的选择。但是让我感到震惊的是他们的推理有多么破碎。如果他们正在进行逻辑论证,他们肯定会考虑 Go,并且会意识到 Go 在他们提出的标准中是一个更好的选择。

我在会议后把工程副总裁拉到一边。“带我了解一下你如何评估其他语言候选项,”我说。他的脸一下子变得空白。“我们……没有真正考虑过其他语言,”他承认。“每个人都在谈论 Rust。”就在那里:一个 5,000 万美元的决定是基于炒作、情感和身份做出的。

对于我来说,这是一个顿悟的时刻,终于回答了我职业生涯早期的疑问。演讲并没有分享分析,他们没有做任何分析;这是对已经做出的选择的辩护。这是一个纯粹基于炒作、情感和身份的决定。

每个技术辩论实际上是两个对话

在每一次语言讨论中,两个对话同时发生。

可见对话: “Rust 有内存安全性,没有垃圾回收。” “Go 有更快的编译时间和更容易的部署。” “Python 有最丰富的机器学习生态系统。”

不可见对话: “我是 Rust 程序员。” “我想成为 Rust 程序员。” “我无法想象自己不选择 Rust。”

如果你读到这里并想“好吧,我的最后一次语言选择是不同的,我是理性的”,你的不可见对话正在运行,正在为自己辩护,同时你读这句话。

我的 CTO 在 Takkle 正在进行不可见对话。每一点可见的 Perl 分析在技术上都是正确的,但感觉像是一场闹剧,因为它只是为了掩盖更深层次的不可见对话。他不是在评估语言。他是在保护他花了十年时间建立的身份。我们公司每月额外支付 30 万美元的费用不是为了更好的架构或更快的招聘。我们支付的是让他成为 Perl CTO 而不是 PHP CTO 的机会。这才是真正的交易。重建只是付款计划。

神经科学的原因:为什么你看不到自己的偏见

在过去 20 年中最迷人的研究之一中,研究人员试图了解为什么人们即使面对相互矛盾的证据,也仍然坚持自己的信念。他们发现的东西从根本上改变了我们对人类决策的理解。

研究人员招募了参与者,并首先找出了哪些信念是每个人身份的核心——他们的核心政治观点,他们的基本价值观,定义他们是谁的信念。然后,在参与者躺在功能性磁共振成像(fMRI)扫描仪中时,研究人员向他们呈现了仔细构建的挑战,这些挑战针对的是基于身份的信念,以及挑战那些他们持有但不是核心身份的信念。

脑部扫描显示了令人惊讶的结果:这两种类型的挑战激活了完全不同的神经通路。

当一个外围信念受到挑战时,脑部的推理中心会正常激活。参与者可以考虑证据,权衡论点,有时甚至改变自己的想法。

但是,当一个基于身份的信念受到挑战时,脑部会像受到物理攻击一样做出反应。负责威胁检测的杏仁体会立即激活。处理情绪痛苦和厌恶的岛叶也会亮起活动。最重要的是,维持自我意识和个人叙事的默认模式网络会进入防御模式,试图保护现有的身份,而不是评估新信息。

换句话说,你的大脑没有权衡证据。它正在保护自己免受存在威胁。

研究人员的结论是:“要考虑另一种观点,你必须想象另一种版本的自己。”

你的大脑无法客观地评估对基于身份的信念的挑战,因为这样做需要暂时拆除定义你是谁的神经架构。这不是一个问题,需要更加理性或努力尝试。使你能够清晰地看到偏见的机制是偏见已经损害的机制。

想想这在实践中意味着什么。每次工程师评估一种不是“他们的”语言时,他们的大脑实际上是在对他们进行反对。他们不仅仅是在分析技术权衡,他们正在思考一个尚不存在的自我版本,这种版本对他们现有的自我版本构成威胁。Python 开发人员阅读关于 Go 性能的案例研究时,他们的杏仁体会悄悄地将每一个案例都标记为需要消除的威胁。Rust 倡导者查看相同的问题时,他们的默认模式网络会构建关于为什么“只有”Rust 才能解决这些问题的叙述。

我们不是在撒谎。我们真的相信自己的推理是合理的。这就是为什么基于身份的思维如此昂贵和不可见的原因。

我们建立了整个行业在错误的对话之上

我们自称为 Pythonista、Gopher、Rustacean,我们把这些标签当作徽章,有时我们甚至戴着真正的徽章(T 恤、贴纸等)。有一个原因可以解释为什么我们很多人的姓氏来自于人们的工艺:Potter、Smith、Brewer。我们做的事情成为我们是谁。看起来像装饰标签的东西实际上是运行在意识之下的决策框架。

我们建立了整个行业在可见对话之上。我们训练工程师辩论技术优点。我们创建了基于功能矩阵的决策框架。我们认为如果我们收集足够的基准测试和案例研究,我们就会做出正确的选择。

但是不可见对话更强大。这就是为什么我的 CTO 选择了 Perl。这就是为什么那位工程副总裁选择了 Rust。这也是在你的下一个语言决策中运作的,无法察觉和未经审查。

你一旦聘用一位 Rust 开发人员来评估语言,你就已经选择了 Rust。你只是添加了一个 200 万美元的可行性研究来使预先确定的决策感觉合理。

真正的成本

问题不是这种偏见是否存在,科学是明确的。真正的问题是:你能否承担让它做出决定的后果?

因为不可见对话有一个价格标签。行业研究表明,技术栈决策占产品生命周期内总开发成本的 40-60%。Stripe 的研究发现,开发人员将 42% 的时间花在技术债务上。当你让身份驱动这个决策时,你正在抵押你的速度、预算和跑道来支付某人的自我意识。

可见对话是关于技术的。不可见对话是关于身份的。而不可见对话总是赢。

一个新的框架:语言作为经济决策

那么,我们如何在不可见对话不断地对我们进行反对的情况下获胜?完全改变对话。

不要问“哪种语言是最好的?”,而要问“这种语言将花费我们多少?”不仅仅是在薪水上,还包括速度、技术债务、招聘难度、运营复杂性等所有实际决定你是否能生存的维度。

将其重新定义为一个技术辩论到一个经济问题。与身份不同,经济可以被衡量、比较和决定,而不会有人受到威胁。

选择一种编程语言是公司将要做出的最昂贵的经济决策。它将定义你的文化,限制你的预算,决定你的招聘渠道,设定你的运营成本,并最终决定你是否能够快速行动以赢得你的市场。

我们需要一个框架,使不可见的成本变得可见。一个允许我们进行经济对话而不是身份对话的框架。一个无论你是选择你的第一种语言还是评估迁移都有效的框架。

我们的行业从来没有真正拥有过这样的框架……直到现在。

评论

(0)
未配置登录方式
暂无评论