DHH：编程的未来、人工智能、Ruby on Rails、生产力与育儿 | Lex Fridman 播客 #474

目录

• 引言

• 编程

• JavaScript

• 谷歌 Chrome 与美国司法部

• Ruby 编程语言

• 优美的代码

• 元编程 (Metaprogramming)

• 动态类型 (Dynamic typing)

• 扩展性 (Scaling)

• 编程的未来

• 人工智能的未来

• 感觉编程 (Vibe coding)

• Rails 宣言：优秀编程语言的原则

• 为什么管理者毫无用处

• 小团队

• 杰夫·贝索斯 (Jeff Bezos)

• 为什么会议是有害的

• 反对退休的理由

• 努力工作

• 我们为什么离开云

• AWS

• 拥有自己的服务器

• 埃隆·马斯克 (Elon Musk)

• 苹果 (Apple)

• 蒂姆·斯威尼 (Tim Sweeney)

• 为人父

• 赛车

• 汽车

• 编程环境配置

• 给初学者的编程语言

• 开源

• WordPress 的闹剧

• 金钱与幸福

• 希望

正文

引言

Lex Fridman

接下来是与 David Heinemeier Hansen（通常被称为 DHH）的对话。他是编程和科技界的传奇人物，才华横溢、见解深刻，有时也充满争议，但与他交谈总是充满乐趣。他是 Ruby on Rails 的创造者，这是一个极具影响力的 Web 开发框架，支撑着包括 Shopify、GitHub 和 Airbnb 在内的许多拥有数百万用户的网站。他是 37signals 公司的共同所有者和首席技术官，该公司创建了 Basecamp、HEY 和 ONCE。

他与合著者 Jason Fried 共同撰写了四本《纽约时报》畅销书：《Rework》、《Remote》、《Getting Real》和《It Doesn’t Have To Be Crazy At Work》。除此之外，他还是一名赛车手，曾在传奇的勒芒 24 小时耐力赛中获得组别冠军。这里是 Lex Fridman 播客。为了支持本节目，请查看描述中的赞助商并考虑订阅本频道。现在，亲爱的朋友们，让我们欢迎 DHH。

编程

Lex Fridman

对于一个后来成为传奇程序员的人来说，你正式接触编程的时间算是比较晚的。我想这是因为你曾几次尝试学习编程都失败了。所以，你能给我讲讲你学习编程失败的完整传奇经历吗？这其中有 Commodore 64 的影子吗？

DHH

Commodore 64 是我的启蒙。我非常想要一台 Commodore 64，那是我第一次接触到的电脑。当时我五岁，我住的那条街上只有一个孩子有 Commodore 64。其他人都没有电脑，所以我们所有孩子都跑到他家去玩《功夫小子》(Yie Ar Kung-Fu)。我不知道你是否见过那款游戏，它是最早的格斗游戏之一。那是一款非常棒的游戏，我五岁时第一次玩，当时大概有七个孩子挤在那个孩子的卧室里，轮流玩游戏。我发现那东西简直有趣得不可思议。我不断地恳求我爸爸：“我能有台电脑吗？”终于有一天他回家说：“我给你买了台电脑。”我当时心想，太棒了，我自己的 Commodore 64。结果他拿出了一台黑、绿、蓝相间的键盘，是 Amstrad 464。我当时就说：“爸爸，这是什么？”

Lex Fridman

太失望了。

DHH

这不是 Commodore 64。但它终究是一台电脑。所以我在六岁时拥有了我的第一台电脑，那台 Amstrad 464。当然，我最想做的第一件事就是玩电子游戏。我记得那台电脑是他用一台电视和一台立体声录音机换来的，附带了两款游戏。一款是《青蛙过河》(Frogger) 类的游戏，你要从地下逃出来，其实有点黑暗，你控制着一只青蛙，试图让它从地下出来。我玩得很差。我只有那两款游戏，然后我就想要更多的游戏。对于一个没什么钱、买不起很多游戏的小孩来说，一个获得更多游戏的方法就是自己把它们敲进去。在 84、85 年那会儿，杂志真的会在后面刊登源代码，你就可以坐下来把它敲进去。

我试着那么做，把一个游戏敲进 Amstrad 大概要花两个小时，而且我肯定会犯一些拼写错误，导致某些地方无法运行……我的英语也不是很好，我是在丹麦出生的。所以我真的很努力想入门，因为我想要所有那些游戏，但我没钱买。我努力了很长一段时间，但就是没能入门。然后我发现了盗版的魔力，之后我基本上就暂停了学习编程，因为突然之间我能玩到各种各样的游戏了。所以那是第一次尝试，大概在六七岁的时候。有趣的是，我记得一些片段。我记得当时不理解变量的用途。

如果有一个东西，你给它赋了值，为什么还要给它赋另一个值呢？出于某种原因，我能理解常量 (constants)，常量对我来说很有意义，但变量 (variables) 就不行。然后大概在我 11 到 12 岁的时候，我接触到了 Amiga。顺便说一句，Amiga 可能至今仍是我心中最喜欢的电脑。你知道，就像人老了会说，“哦，80 年代的音乐太棒了。”对我来说，即便作为一个热爱电脑和新电脑的人，Amiga 也是一台神奇的机器，它和 Commodore 64 是同一家公司生产的。我大概在 87 年得到了 Amiga 500。

Lex Fridman

看看这性感的东西。这真是一台性感的机器。

DHH

顺便说一句，那是一个计算还不像现在这样全球化的时代，不同地区流行的电脑也不同。Amiga 在欧洲非常流行，但据我所知，在美国根本不流行。它在日本也不流行。当时有各种不同的机器。Apple II 在美国很火。80 年代在哥本哈根，我甚至都没听说过苹果。但 Amiga 500 是那台让我再次想尝试编程的机器。有趣的是，我之所以想再试一次，是因为我记得第一次尝试学习时，有一种编程语言名字就叫 EasyAMOS，就像是 AMOS 的简单版。我想，既然叫 EasyAMOS，能有多难呢？我肯定能搞定。

这次我更努力了。我学了条件语句、循环和各种东西，但还是不行。在第二次尝试时，我真的开始觉得，也许我不够聪明。也许是数学太多了。我只是肤浅地喜欢数学，不像我那些可能更 nerdy 的朋友那样深入地喜欢，我非常尊敬他们，但我不是那种人。我不是那种能把所有问题都解决的数学迷。所以在用 EasyAMOS 尝试并失败后，我甚至觉得我连一个最基本的游戏都没完成。我想，编程可能不适合我。我得做点别的。我仍然喜欢电脑，仍然喜欢电子游戏。

实际上，在那个时候，我已经开始和一些会编程的朋友交往了，他们甚至都不是用 EasyAMOS 编程，他们用的是该死的汇编语言。我坐下来看，那些 move、memory、copy 指令，你们是怎么做到的？我甚至不明白你们是怎么从这些指令做出 Amiga 的演示程序 (demos) 的。那是 Amiga 上的大热门。它在欧洲有一个非常棒的演示场景 (demo scene)。在 Amiga 的历史上，那是一个非常有趣的时期，所有这些程序员大多分布在欧洲各地，他们会参加图形竞赛，你可能会带来一些……

Lex Fridman

就用那台机器？

DHH

就用这台机器。他们会制作一些类似音乐视频的小短片，结合一些 MIDI 音乐和炫酷的图形，而且他们会把所有这些东西都塞进 4K 的空间里。是 4 KB (kilobytes)，不是 4K 分辨率。是 4 KB 的内存。我觉得那个圈子太酷了。这显然是在互联网出现之前，甚至在某种程度上是在 BBS（电子公告板系统）出现之前。你要和别人交换你的演示软件，就得用邮寄的方式，寄一张 3.5 英寸的软盘。我完全被那个圈子迷住了，被他们能创造出的东西迷住了，我只想成为其中的一员，尽管我好像没有任何可以贡献的技能。就这样，我开始运营 BBS。

我当时没有学习编程，直到很久以后，快 20 岁的时候才学会。电子公告板系统存在于一个有趣的空间里，它们部分是为演示场景服务的，让所有这些演示团队分发他们惊人的演示程序。同时，它也是一个交易盗版软件的地方。我在 14 岁时，在哥本哈根我那小小的卧室里创办了一个这样的 BBS。当时我用的是 Amiga 4000，我的小房间里接了三条电话线。

Lex Fridman

厉害。

DHH

这很有趣，因为当时我才 14 岁。当我安装第三条电话线时，你得找电话公司的人来安装。来的那个人四处张望，心想这是什么情况？为什么一个 14 岁的孩子要在自己小小的卧室里接三条电话线？这里到底发生了什么？为什么所有这些调制解调器 (modems) 都在闪烁着红黑色的灯，还发出奇怪的声音？

Lex Fridman

你父母知道吗？

DHH

他们既知道又不知道。他们知道我有电话线，也知道我有电脑。我想他们并不真正理解我在交易盗版软件，这既是违法的，也伴随着其他各种事情。

Lex Fridman

哦，我们或许应该说，在欧洲，也许你能评论一下，尤其是在东欧，但在整个欧洲，盗版行为的接受度可能比在美国要高。我不知道，也许这只是我成长环境的原因……

DHH

甚至连那样的对话都没有。我在丹麦长大的过程中，从来没有和任何人谈论过……

Lex Fridman

盗版是错误的。

DHH

……任何人对盗版有任何道德上的疑虑。大家完全接受这个事实：你是个孩子，想玩很多游戏，但又没什么钱。你该怎么办？你就去交换。有些人偶尔也会买游戏。比如，我曾经买过一台世嘉 Master System，还买了一盘游戏，因为那是我能负担得起的。我买的是《冲破火网 II》(After Burner II)，不知道你玩过没有。它在世嘉 Master System 上的实现其实很糟糕，但它大概要 600 克朗。

我当时靠送报纸赚钱。我得送一个月报纸才能买得起一盘游戏。我太喜欢电子游戏了，等不了一个月才玩到一盘新游戏。所以盗版就是当时的方式，我也是这样开始运营这个 BBS，成为演示场景和某种程度上盗版场景的一员。后来我也意识到，哦，原来这也能赚钱，这笔钱可以用来买更多的电话线、更多的调制解调器和更多的 Amiga。哦，是的，那是一次演示派对。这些活动太棒了。

Lex Fridman

我看到的是什么？

DHH

是不是很神奇？

Lex Fridman

看那些 CRT 显示器。

DHH

所有这些 CRT 显示器。同样，在我 14 岁的时候，我完全不理解为什么我父母会允许这样。我从丹麦的首都哥本哈根，坐火车去了一个叫 [听不清] 的日德兰半岛小镇，和一群十几岁、二十几岁的家伙一起。我才 14 岁，背着我的 14 英寸 CRT 显示器和电脑去参加派对。那就是当时所谓的“派对”，是当时最大的演示场景派对。就像你在那张照片里看到的一样，成千上万的人排着队，带着他们的电脑，整天编程做演示，来回交换这些东西。

Lex Fridman

那还挺酷的，说实话。虽然有点夸张。

DHH

那简直太酷了，我很怀念那种感觉。互联网在某些方面连接了人们，但那种你和另一个人并肩而坐的连接感，他也有自己的 CRT 显示器，为了到这里，他把它从半个国家外拖过来，这种感觉真的很特别，因为它也是一种创造力的爆发。你不断地在人群中穿梭，周围都是在自己领域非常出色的人，他们非常擅长编程。这很有感染力。这也是我当时感到痛苦的一部分原因，我会想：“天啊，为什么我就是搞不懂呢？为什么我连 EasyAMOS 都搞不定？”这挺令人沮丧的。

Lex Fridman

但你的第三次尝试就成功一些了。

DHH

第三次尝试时，我开始入门了。那时候我开始帮忙为互联网做一些东西。大概是在 95 年或 96 年，我发现了互联网。实际上是在九年级，那是我第一次接触。我去了丹麦的一所大学，九年级时我们有一次校外考察，他们让我们坐在一台电脑前，电脑上装的是 Netscape Navigator，第一版，或者甚至是它的前身。他们还提供了一个文本编辑器，然后对我们这些孩子说：“嘿，在互联网上做点东西吧。”当时只有 HTML，你做的第一件事就是，“哦，我只要输入这个标签再保存，就能让文字闪烁？”那一刻，实际上重新点燃了我学习编程的渴望，因为我获得了一次积极的体验。

我之前所有关于编程的经历都是，我花几个小时输入一些东西，点击运行，然后它就不工作了，弹出一个错误信息，无论是在我六七岁还是十二岁的时候，我都看不懂。而现在，我坐在一台连接着互联网的电脑前，我能让文字闪烁，能让它变大，能把它变成 H1 或 H2。我们就在那里玩了一个半小时，突然间我意识到，“哦，我能为互联网制作东西，德国的人也能访问和看到，而且我不需要征求任何人的许可？”这太酷了。我必须多做这个。于是我进入了互联网领域，开始使用 HTML，我还有那些在演示派对上认识的朋友，我和他们一起创建游戏网站。

我更愿意自己买电子游戏，然后写评测。这是另一种获得新电子游戏的好方法，就是走到某家商店说：“嘿，我是记者。”我当时大概十五岁，他们看着我。“你是记者？”“是的，我能借一些游戏吗？”因为当时游戏已经转移到 PlayStation 和其他平台上了，盗版不像以前那么容易了，至少一开始是这样。所以我去了那里，做了所有这些事，这开启了我的互联网之旅。我开始做这些游戏网站，和程序员一起工作，发现我能做点什么，我可以负责 HTML 部分。

这不完全是编程，但感觉有点像。你在和电脑对话，让它在屏幕上显示文字，你在和半个地球外的人交流。所以这成了我重回编程之路的途径，然后我慢慢地学到了越来越多。我参与的第一个动态网站，是和一个来自演示场景的程序员一起做的，用的是 ASP.NET。当时甚至还不叫 .NET。我们是从那个开始的，然后转向了 PHP。当我接触到 PHP 时，我终于明白了，终于开窍了，条件语句、循环、变量所有这些东西对我来说开始变得足够有意义，以至于我认为，我能做到。

Lex Fridman

所以说，没有 PHP 就没有 DHH，因此你所有的成功都归功于 PHP，这样说公平吗？

DHH

百分之百正确。而且还不止于此，因为 PHP 对我来说，不仅是在制作自己的 Web 应用方面给了我一个起点，它实际上还给了我一个标杆。在很多方面，我认为 Web 开发者人体工程学的巅峰就是 90 年代末的 PHP。你写一个脚本，用 FTP 传到服务器上，它就立刻部署好了，立即可用。你修改文件里的任何东西，刷新一下，马上就看到了。没有 Web 服务器，没有配置。只有一个运行着 mod_php 的 Apache。这基本上是让一个动态网页上线运行最简单的方式了，而这也是我职业生涯余下时间里一直在追寻的那种快感。在 90 年代中后期，为互联网制作东西是如此简单。

我们是如何失去了那种让我们不仅能以这种方式工作，还能吸引新人进入这个行业，给予他们像我当年添加一个闪烁标签到 HTML 页面、或者在对框架、配置一无所知的情况下用 FTP 将一个 PHP 页面上传到 Apache Web 服务器那样的成功体验的呢？所有这些东西真的把我们带到了一个有时感觉几乎没有进步的地方。如今的网页和 90 年代末、2000 年代初的网页并没有太大区别。它们仍然只是表单，仍然只是向数据库写入数据。

我想，很多人对于自己本质上只是 CRUD 猴子（crud monkeys）这一事实感到非常不安。他们构建的系统只是在数据库中创建、读取、更新或删除数据行，他们必须通过过度复杂化来弥补这种存在主义的恐惧。当然，这有点夸张了。事情还有更多层面，你也可以从更复杂的思维方式中学到东西，但这里仍然有一个理想，这也是为什么我很高兴你邀请了 Pieter Levels，因为他基本上仍然是这样工作的。我看着他，心想，天啊，这太神奇了。

Lex Fridman

是啊，你在追寻那种快感，而他一直都沉浸其中。

DHH

是的。

Lex Fridman

用 PHP、jQuery 和 SQLite。

DHH

我觉得这很了不起，因为他证明了这不仅仅是一个怀旧的梦想。他真的在这样做，运营着所有这些业务。当然，正如他会首先承认的，其中一部分原因是他只是一个人。当你只是一个人时，你可以做一些不同的事情。当你开始在一个团队中工作时，当我开始和 Jason Fried 一起开发 Basecamp 时，我们最初并没有一起使用版本控制。

我为自己使用版本控制，然后我想，你知道吗？设计师可能不够聪明，搞不定 CVS，所以我当时就说：“不不不，你直接用 FTP 上传就行了。”他们知道怎么用 FTP。结果在我第三次覆盖了他们的修改之后，我说：“该死的，看来我得教 Jason 用 CVS，免得再发生这种事。”但我认为，我们仍然可以在团队环境中像 90 年代那样工作，像 Pieter 今天那样工作，这个观点有更多的道理。我们太愿意把太多的开发者人体工程学交给那些复杂性的商人了。

JavaScript

Lex Fridman

而且你一直在用 Rails 8 追寻那种感觉。那么，你如何将现代框架的所有酷炫功能整合起来，同时又做到“无构建”(no build)，让创造和发布东西变得像 90 年代用 PHP 一样简单？对我来说，要超越 Pieter Levels 那种简单直接的方法非常困难……用 PHP 发布一些东西实在是太容易了。

DHH

就应该这样。为什么会比那更难呢？我们今天的电脑比 90 年代快了几乎无限倍。所以我们难道不应该能用更简单的方式工作吗？我们应该回顾 90 年代然后说：“哦，那时候太复杂了。现在我们有了更先进、更快的技术，让我们能用这些更简单易用的方式工作。”但事实并非如此。不过现在你可以看到我在 Ruby on Rails 工作中，尤其是在 Rails 8 中划出的那条线。“无构建”(No build) 对我来说，就是回溯到 90 年代的感觉，然后说，现在我们可以做一些那样的事情，而不用放弃所有的进步。因为我确实认为人会变得过于怀旧，会开始幻想 90 年代的一切都更好。事实并非如此。

我经历过那个时代，有很多糟糕的事情。如果我们能设法将过去 20 年的优势和进步与那种简单的开发者人体工程学结合起来，我们就能赢。“无构建”是对过去 10 到 15 年 Web 开发中我最讨厌的部分——也就是 JavaScript 生态——的一种拒绝。我这么说并不是因为我讨厌 JavaScript。我经常开玩笑说 JavaScript 是我第二喜欢的编程语言。虽然是遥远的第二名，Ruby 遥遥领先是第一名，但我其实喜欢 JavaScript。我不认为它是一门糟糕的语言。它受到了很多抨击。人们把字符串 "2" 和 "1" 相加，得到了一个无厘头的结果，我就会想，是啊，但你为什么要那么做呢？别那么做就行了。这门语言其实很可爱，尤其是现代版本。

ES6 真正为它引入了合适的类语法，所以我可以用许多与我喜爱的 Ruby 相似的方式来使用 JavaScript。这让事情变得好多了。但在 2010 年代初直到不久前，所有的进步都发生在预处理和构建管道中。浏览器无法理解一种令人愉快的 JavaScript 方言，所以每个人都开始预编译他们的 JavaScript，以便能够在一个被认为停留在古老 JavaScript 版本的浏览器上使用更现代的编程方式，而那个版本没人真正想用。这对我来说有道理，但过程也深感不快。我记得在那个时期，也就是我所说的 JavaScript 的黑暗时代，我心想，这不可能是最终的目的地。我们不可能把互联网变成一个如此不愉快的工作场所，以至于我开始用 Webpack 和所有这些依赖项来开发一个 JavaScript 项目，放下它仅仅五分钟，它就无法再编译了。

在 2010 年到 2020 年的十年间，JavaScript 社区，尤其是其框架和工具链，所经历的变动量是荒谬的。你必须被困在那个疯人院里，才能不意识到我们陷入了一个何等荒谬的境地。为什么所有东西总是坏掉？我的意思是，不仅仅是软件会坏掉，这会让我个人感到烦恼。然后我会上 Hacker News，看到某个关于最新 JavaScript 框架发布的帖子，帖子里会有人问：“我们不是还在用三个月前的东西吗？”然后人们会说：“那东西太老土了。那是三个月前的事了。你得跟上新潮流，我们正在为了[听不清]次完全重写所有东西，你在上一个框架上学到的任何东西都毫无用处。你得把所有东西都扔掉，重新开始。你为什么还不这么做，你这个蠢货？”

Lex Fridman

你认为那是一种席卷了开发者社区的群体性歇斯底里吗？就是你必须不断创造新的框架，然后又创造新的框架，我们现在走出那个黑暗时代了吗？

DHH

我想我们正在走出来，我们能走出来是因为浏览器变得好太多了。浏览器技术曾一度停滞不前。其中一些是 IE5 遗留下来的问题。IE5 基本上把整个互联网开发体验带入了一个深度冰冻期，因为微软在 21 世纪中期赢得了浏览器战争，然后他们基本上解散了他们的浏览器开发团队，因为他们觉得：“好了，任务完成了，我们不需要在互联网上再有任何创新了。既然我们控制了一切，我们能不能回去写 Windows Forms 之类的东西？”直到 Firefox 燃起了一点星星之火，然后 Chrome 进入市场，谷歌开始认真推动 Web 向前发展，你才看到一丝希望，也许浏览器可以变得更好。也许浏览器并没有停留在 2005 年的时间里。也许浏览器可以像它本身就是一个开发平台那样不断进化。但后来发生的是，大量聪明的人涌入了 Web 领域，因为 Web 最终成为了有史以来最伟大的应用开发平台。这里是所有财富被创造的地方，所有亿万富翁诞生的地方。Facebook 等公司就是在这里崛起的。所以有这么多智慧投入到如何使用 Web 的问题上，其中一些非常聪明的人，带着一些我确信很好的想法，但他们的首要动机并不是程序员的幸福感。他们有其他的优先事项，而这些优先事项让他们忽视甚至合理化了他们到处注入的复杂性。其中一些复杂性来自于组织结构。当你有一个像 Facebook 这样的公司，它依赖于 Web 并希望推动其发展，但却把开发岗位切分成了这些微小的细分领域……“我是一个前端 glob 管道配置员。”

“哦，是吗，我是一个前端 XXX 工程师。”突然之间，Web 开发者不再是一个人，而是 15 个不同的角色。这本身就注入了大量的复杂性。但我也想为这种复杂性辩护，那就是其中一些复杂性是达到我们今天这个地步所必需的，这种复杂性是一座桥梁。它不是目的地，但我们必须跨过这座桥才能到达今天，浏览器已经变得非常不可思议。你现在可以在一个文本文件中编写 JavaScript，然后把它放到一个 Web 服务器上供浏览器读取，这种体验太棒了。这实际上是一种非常好的体验。你不需要任何预处理。你可以直接写文本文件，发送给浏览器，就能获得一个令人难以置信的开发……

Lex Fridman

我们还应该说，它在某种程度上可以被破坏，至少 HTML 是这样，甚至 JavaScript 也可以有点问题，但它还是能用。也许是勉强能用，但浏览器需要处理的那些杂乱、糟糕的代码量简直是疯了。

DHH

这是当今计算领域最棘手的问题之一，就是解析整个互联网。因为，对我们 Web 开发者来说是幸运的，但对浏览器开发者来说可能就不是了，除了 Flash 短暂流行过的那段时间，所有曾经创建的网页至今仍然可以运行。我在九年级做的那个网页，30 年后的今天，仍然可以在现代浏览器上渲染出来。

Lex Fridman

那太疯狂了。

DHH

当你想到 Web 已经经历了多少演变，我们把它变得多么好，浏览器采纳了多少新标准，这简直是完全疯狂的。今天，要创建一个新的浏览器，基本上相当于一个阿波罗计划，这就是为什么这种事不常发生，这也是为什么即使像微软这样的公司也不得不认输，说：“我们做不到。”现在，我其实不认为这对 Web 是好事。如果我们只有一个浏览器引擎来运行所有东西，就会有单一文化的危险，我们正处于这种危险之中。我很高兴 Ladybird 项目正在尝试从头开始制作一个新的浏览器引擎。我支持那个项目，也鼓励大家去了解一下。这真是一件很棒的事情。它由一群曾在其他浏览器项目工作过的人员组成。

Lex Fridman

一个真正独立的 Web 浏览器。

DHH

我们真的需要这个。但我可以同时持有这个想法，也持有另一个想法，那就是谷歌 Chrome 对于 Web 作为首要的 Web 开发平台能够存活下来至关重要。如果不是谷歌以及他们整个业务都依赖于一个繁荣开放的 Web，我想苹果和微软会很乐意看到 Web 消失，变成只是为他们完全控制的原生移动应用和原生桌面应用服务的东西。所以，我对谷歌有很多意见，但 Chrome 不在其中。Chrome 对全世界的 Web 开发者、对 Web 这个开发平台来说，完全是一份礼物，我认为他们为此应获得巨大的赞誉。即使这与他们的商业模式纠缠不清，Chrome 中有一半的代码是在监视你或为定向广告服务，以及一些我并不喜欢的其他东西，我也可以将这一点与这样一个事实分开来看：我们需要在 Web 的阵营里有这样的拥护者，他们的市值有数万亿美元是建立在开放 Web 之上的。

谷歌 Chrome 与美国司法部

Lex Fridman

我们要在一个接一个的岔路上越走越远了。所以我们来谈谈 Chrome。我认为 Chrome 对人类的积极影响是无法估量的，原因就是你刚才描述的那些。在技术方面，它所带来的功能和它创造的竞争，激发了 Web 技术的蓬勃发展。但无论如何，我必须问你关于最近美国司法部 (DOJ) 试图拆分 Chrome 和谷歌的事情。你认为这是个好主意吗？你觉得这会造成伤害吗？

DHH

这是一场灾难。我这么说，是作为一个一直对反垄断斗争抱有同情态度的人，因为我确实认为我们在技术领域存在反垄断问题，但基本上，我们在浏览器领域，在我们用来访问开放网络的工具上，并不存在这些问题。首先，我们有 Firefox。现在，Firefox 的表现不是很好，而且多年来一直由谷歌支持，以避免现在司法部正在发生的事情，即他们是市场上唯一的玩家。苹果有 Safari。我对苹果也有一堆意见，但我喜欢 Safari。我喜欢这样一个事实：我们有一个运行在顶级操作系统上的顶级浏览器，人们无法将网络变成纯粹的 Chrome 体验。但我也认为，开放网络需要这个万亿美元级别的拥护者，或者至少能从中受益。

也许它不是必需的，但肯定能从中受益。在技术领域所有关于垄断形成的问题中，Chrome 是最不应该被关注的，这也是为什么我有时对反垄断斗争感到如此沮丧，因为存在真正的问题，我们应该首先关注最重要的问题，比如我们手机上的收费站。有比这大得多的问题。问题不在于开放网络，也不在于我们用来访问开放网络的工具。如果我不想用 Chrome，如果我的企业客户不想用 Chrome，他们不必用。我们从来没有被强迫使用它。开放的互联网仍然是开放的。所以，我认为司法部选择以这种方式追究谷歌，实在是一件憾事。我确实认为还有其他事情可以追究谷歌，比如他们的广告垄断，或者他们在控制广告供需两端所做的手脚。

这些是问题。Chrome 不是问题。而你最终会让网络变得更糟。这是我们在考虑立法、考虑反垄断斗争时必须永远记住的事情：你可能不喜欢今天的样子，你可能想做点什么，但你也可能让事情变得更糟。欧洲 GDPR 背后的良好意图，目前带来了什么？带来了全网人人都讨厌的 Cookie 横幅，它对任何人都没有任何帮助，没有提高任何效率，没有以任何方式保护隐私，完全是一个浪费时间和金钱的项目，只让律师、会计师和官僚们发了财。

Lex Fridman

是啊，你说过 Cookie 横幅是欧洲在科技领域表现最差的纪念碑。

DHH

它是善意直通地狱的纪念碑，而欧洲在善意直通地狱这方面是世界级的。

Lex Fridman

所以地狱就是那个“接受所有 Cookie”的按钮，你必须接受所有 Cookie。地狱就是那个样子。一遍又一遍，你永远也到不了那个网页……

DHH

只是在一个……

Lex Fridman

……一遍又一遍。你永远也到不了那个网页。

DHH

从人的角度来看，试着想象一下每天有多少小时浪费在点击那个按钮上，我们又因为它们对网络这个人们喜爱的平台造成了多大的伤害。互联网变得丑陋，部分原因就是 Cookie 横幅。Cookie 横幅本应把我们从广告中拯救出来，而广告确实能让网络变得丑陋。这方面的例子很多，但 Cookie 横幅一下子就让整个互联网变得丑陋，这完全是一场悲剧。但更糟糕的是，这也是为什么我称它为欧盟所有错误做法的纪念碑，那就是我们知道这一点已经有十年了。任何一个严肃的人都不会相信 Cookie 横幅对任何人有任何好处，但我们却无法摆脱它。

有一项立法，现在我想已经有 10 或 12 年了。它在任何可以想象的指标上都是彻底的失败。所有人都普遍讨厌它，但我们似乎对此无能为力。对于任何一个声称或意图为不仅是公民，而且是全世界人民改善事物的官僚机构来说，这都是一份破产声明。关于 Cookie 横幅，真正让我恼火的也是这一点。这不仅仅是欧盟的问题，而是全世界的问题。在这个星球上，你无处可躲。就算你坐着埃隆的火箭去了该死的火星，试图访问一个网页，你还是会看到 Cookie 横幅。宇宙中没有人能幸免于这种无稽之谈。

Lex Fridman

可能火箭上的界面也是。

DHH

那会更慢。你基本上有 150 秒的 ping 延迟，所以从火星上光是通过 Cookie 横幅就要花 45 秒。

Lex Fridman

好吧，让我们回到我们一直在进行的这个递归式岔路的话题栈上。所以 Chrome，我们应该说，至少在我看来，它的胜利不是不公平的。它是通过做得更好而公平获胜的。

DHH

是的。如果我只是为另一方辩护半秒钟，人们会说，嗯，也许是的，大多数人都有点不情愿地承认 Chrome 是一个相当不错的浏览器。但他们会说，它之所以能占据主导地位，是因为分发渠道，而它能获得分发渠道是因为谷歌也控制着 Android，因此可以把 Chrome 设为所有这些手机上的默认浏览器。

现在，我不买这个账，我不买账的原因是，在 Android 上，你实际上是允许搭载一个不同于 Chrome 的浏览器引擎的浏览器的。而不像在 iOS 上，如果你想发布一个浏览器，比如 Chrome for iOS，它其实不是 Chrome，而是披着 Chrome 外衣的 Safari，iOS 上的每一个替代浏览器都必须使用 Safari 的 Web 引擎。那不是竞争。那不是在 Android 上发生的事情。

再说一次，我认为这里面有一些细微的差别，但如果你放大视野，看看我们在大型科技公司方面遇到的所有问题，Chrome 并不在其中。Chrome 是靠实力取胜的。我最终也勉强地转用了 Chrome，仅仅是基于这个认识。作为一名 Web 开发者，我就是更喜欢它。我在很多方面都喜欢 Firefox，我喜欢它的精神，但 Chrome 就是比 Firefox 更好的浏览器，句号。

Lex Fridman

顺便说一句，我们从来没提过 Edge。Edge 也是一个不错的浏览器。

DHH

因为它也是披着外衣的 Chrome。

Lex Fridman

但它从来没有得到过应有的喜爱。我想我从来没用过必应 (Bing)，但我肯定必应也很好。

DHH

也许你用过，因为你知道什么东西是披着必应外衣的吗？

Lex Fridman

什么？

DHH

DuckDuckGo。

Lex Fridman

什么？

DHH

这其实是我用的搜索引擎。DuckDuckGo 的搜索结果来自必应，或者至少以前是。如果他们改了，那对我来说就是新闻了。

Lex Fridman

嗯，也许所有东西都只是一层包装或者一件外衣。所有东西下面都穿着另一件衣服。还有其他的乌龟……

DHH

确实有那么点意思。

Ruby 编程语言

Lex Fridman

乌龟，那件衣服一直穿到底。好吧，我们刚才在谈什么？我们是从 JavaScript 和你学习编程的经历聊到这里的。所以最终，当你用 PHP 做了很多东西并真正开始交付产品时，你获得了巨大的成功。

DHH

是的。

Lex Fridman

然后 Ruby 的故事就开始了。你对编程的热爱就从那里开始了。所以，你能带我回到那个时候吗？Ruby 是什么？给我讲讲 Ruby 的故事。给我解释一下 Ruby。

DHH

PHP 是那个把我从一个只会摆弄 HTML、做几个网页的人，转变成一个能够自己制作 Web 应用程序的人的语言。所以，在这方面我非常感谢 PHP。但我从未把 PHP 看作是一种使命。我不是那种会说：“我是一个写 PHP 的专业程序员，这就是我的身份，这就是我做的事。”我把 PHP 看作是我需要用来敲打电脑，直到它产出我想要的 Web 应用程序的工具。它很大程度上是达到目的的手段。我没有爱上 PHP。我很感激它教会了我编程的基础，也很感激它为我设定了人体工程学的标准。但直到接触了 Ruby，我才开始把自己看作一个程序员。事情是这样的，我第一次作为专业程序员被雇佣来写代码，实际上是 Jason Fried，他现在仍然是我的商业伙伴。

那是在 2001 年，当时我已经用 PHP 做了大约 18 个月的游戏网站。在那方面，还没有人付钱让我写代码。我通过一封从丹麦哥本哈根发往伊利诺伊州芝加哥的邮件联系上了 Jason Fried，而他当时并不知道我是谁。我只是主动提供了建议。Jason 在网上问了一个问题，我发给了他答案，他问的是 PHP，我给了他那个问题的答案，然后我们开始交谈，接着就开始合作了。顺便说一句，这是互联网所能带来的奇迹。一个在哥本哈根的孩子，怎么能和一个在芝加哥从未谋面的人，仅仅通过邮件就联系上并开始合作？顺便说一句，我们现在，24 年后，仍然在合作。这太不可思议了。但我们开始合作，开始做一些客户项目。

Jason 负责设计，37signals 负责设计，我负责编程，用的是 PHP。在我们用 PHP 合作了大概两三个客户项目后，我们总是遇到同一个问题：当你和客户合作时，项目总是从一封邮件开始，“哦，好的，我们合作吧。这是我们要做的东西。”然后你们开始交换越来越多的邮件，几周过去后，你需要把新人加到项目里。他们没有之前的邮件，没有上下文。你发给他们，“最新的文件在哪？”“哦，我上传到 FTP 上了，文件名是‘最终版_最终版_V06_2.0’。”对吧？就是那个。这简直是一团糟，虽然在某些方面也是一种美丽的混乱。至今，绝大多数项目仍然是这样运行的。电子邮件是最低的共同标准，这很棒。

但我们有几次在客户面前犯了严重的错误，我们觉得我们可以做得更好。我们知道如何制作 Web 应用。我们难道不能做一个比电子邮件更好的项目管理系统吗？应该不会那么难吧。我们做过博客，做过待办事项列表。让我们把这些东西组合起来，做一个系统，让所有参与项目的人需要的一切都在一个页面上。而且它必须足够简单，我不需要办个研讨会来教你怎么用这个系统。我只要给你登录信息，你就能直接上手。那就是 Basecamp。当我们开始开发 Basecamp 时，我第一次在和 Jason 的合作中拥有了技术选择的自由。没有客户告诉我：“嗯，PHP 听起来不错。我们懂 PHP。你能用 PHP 来做吗？”

我有了完全的自由。那时我一直在读《IEEE Magazine》和其他一些 2000 年代初的杂志，Dave Thomas 和 Martin Fowler 一直在上面写关于编程模式和如何写出更好代码的文章。这两位尤其都用 Ruby 来解释他们的概念，因为 Ruby 看起来就像伪代码。无论你是用 C、Java 还是 PHP 编程，这三类人都能看懂 Ruby，因为它基本上读起来就像英语。所以他们用 Ruby 来描述概念，我首先会为了他们解释的概念去读这些文章，然后我会想：“这是什么编程语言？”我的意思是，我喜欢你解释的概念，但我也想看看这门编程语言。我怎么没听说过这个？

所以我开始研究 Ruby，我意识到在那个时候，Ruby 可能还不为人知，但它实际上已经存在了很长时间。Ruby 的日本创造者 Matz 早在 93 年就开始研究 Ruby 了，那时互联网甚至还没出现。而我是在 2003 年，十年后，发现了这个似乎被埋没在默默无闻中的隐藏瑰宝。但 Dave Thomas 和 Martin Fowler，我认为他们成功地让我和少数其他人走上了一条探索一门在西方使用不多但潜力巨大的编程语言的道路。所以我接触了 Ruby，心想，这很不一样。首先，分号都去哪儿了？我一直在用 PHP、ASP 编程，甚至还做过一些 Pascal，看过一些 C。到处都是分号。

这是第一件让我震惊的事情，那些该死的分号去哪儿了？我开始思考，其实，我们为什么在编程中有分号？它们是用来告诉解释器这是一条新的指令行，但我作为人类并不需要它们。哦，有人在这里是为人类着想，而不是为机器。这真的让我产生了兴趣。然后我对自己说，你知道吗？我 PHP 挺熟的。我不是一个了不起的程序员，我从事编程的时间也不长，但也许我能搞定。我给自己两周时间。我要写一个概念验证，和数据库对话，取出一些记录，稍微格式化一下，然后在一个 HTML 页面上显示出来。我能在几周内搞定这个吗？结果大概只用了一个周末，我完全被迷住了。我完全被震撼了，因为 Ruby 就像是为我的大脑量身定做的手套，而且是一个我素未谋面的人做的。这怎么可能？

优美的代码

Lex Fridman

我们或许应该描绘一下 Ruby 所具备的某些特质，甚至可以和 PHP 比较一下。我们还应该提到，PHP 里有一个我习以为常却又很荒谬的东西，那就是到处都是美元符号。

DHH

是的。

Lex Fridman

PHP。我的意思是……

DHH

是的，那是行噪声 (line noise)。

Lex Fridman

行噪声。

DHH

我喜欢这么叫它。

Lex Fridman

行噪声。行噪声。这个词太美了。所以有很多看起来像程序的东西，而用 Ruby，虽然和 Python 有些相似之处，它看起来就像自然语言。你可以正常地阅读它。

DHH

这是一个可以循环五次的 while 循环。你可以直接输入数字 5，然后一个点，现在我正在调用数字 5 上的一个方法。顺便说一句，这是 Ruby 最美的方面之一，像整数这样的基本类型也是对象，你可以调用 5.times，然后加上括号。现在你就在括号里的代码上迭代了五次。就是这样。

Lex Fridman

哦，那不错。

DHH

这不仅仅是不错，这是卓越。据我所知，没有任何其他编程语言能像这样，将一个五次迭代的代码块中几乎所有其他编程语言都会注入的行噪声给剔除掉。

Lex Fridman

哇。这真是个很棒的……嗯，谢谢你举这个例子。这是个很美的例子。哇，我想不出有哪门编程语言能做到这一点。这真的很好。

DHH

Ruby 充满了这样的例子。让我举几个例子，因为我真的认为这有助于描绘出这幅图景，并且让我先声明一下，我其实喜欢 Python 的精神。我认为 Ruby 和 Python 社区有很多相似之处。它们都是动态解释型语言，都专注于即时性、生产力和易用性等多个方面，但它们在许多其他方面又非常不同。其中一个很大的不同之处在于审美。

对我来说，Python……我希望不要太冒犯人，我以前也说过，它就是丑。它的丑陋是根源性的，因为它充满了多余的指令，这些指令是 Guido 在 87 年创造 Python 时的历史遗留问题，到了 2025 年还在这里，我的大脑无法接受。让我举个基本的例子。当你在 Python 中创建一个类时，初始化方法，也就是起始方法，是 def，好的，这和 Ruby 一样。D-E-F 是方法的定义。然后是 __init__，不是一个下划线，是两个，然后是 __，括号开始，self，逗号，然后是第一个参数。

Lex Fridman

是啊，那个 self 的东西。是的。

DHH

我看着这个就想，“对不起，我受不了了。我做不到。”它的每一个方面都从根本上冒犯了我的审美。所有新对象或类都必须实现的最重要的方法，居然是我见过的最不美观的 initialize 写法之一，而你们居然能接受？

Lex Fridman

嘿，你搞得我……你知道吗，你这像是在谈论我的婚姻，而我一直没意识到自己处在一段有毒的关系中。我已经习惯了。

DHH

对我来说，顺便说一句，那正是 Ruby 的魔力所在。

Lex Fridman

问题就在这。

DHH

它让我看到了程序可以有多美。我以前不知道。我一直在用 ASP，一直在用 PHP。我甚至没有“美学”、“优美的代码”是可以优化的东西这个概念。我们可以追求它，甚至可以把它置于其他目标之上。Ruby 之所以如此优美，不是偶然，也不容易。Ruby 本身是用 C 实现的。解析 Ruby 代码非常困难，因为 Ruby 是为人类编写的，而人类是复杂的生物。他们喜欢事情恰到好处。我无法完全解释为什么 __init__ 让我反感，但它就是让我反感。而当我看到 Ruby 的替代方案时，就非常有启发性。它也是 def，同样的部分，D-E-F 空格，initialize，括号，如果你不需要在参数中调用它，甚至连括号都没有。

这本身也是一个主要的部分。如果人类不需要额外的字符，我们就不会仅仅因为这样对计算机解析更友好而加上它们。我们要去掉分号，去掉括号，去掉下划线，去掉所有那些丑陋的东西，所有那些行噪声，把它精炼到最纯粹的本质。同时，我们也不做缩写。这也是 Ruby 和 Python 在美学上的一个关键区别。init 打字更短，只有五个字符。initialize 要长得多，但看起来好得多，而且你不会经常打它，所以你应该看一些漂亮的东西。如果你不必一直做这件事，那么长一点也无妨。

这类审美评估在 Ruby 语言中随处可见。但让我给你一个更好的例子。if 条件语句，这是所有编程语言的基石。它们都有 if 条件语句。如果你看大多数编程语言，它们会有 if，这在几乎所有语言中都基本相同，空格，左括号，我们都这么做。然后你可能会有，比如说，你在调用一个叫 user 的对象的 is_admin 方法，右括号，右括号，左花括号，然后是如果用户是管理员我们要做的事情，对吧？那是一种常规的编程语言。Ruby 不这么做。Ruby 几乎把所有这些都精简掉了。我们从 if 开始。好的，那是一样的，不需要括号，因为对人类来说没有歧义来区分下一部分只是一个单一的语句。所以你写 if 空格 user.admin?，没有左花括号，没有括号，什么都没有。下一行，就是你的条件语句。

那个问号对电脑来说没有任何意义，但对人类来说有意义。Ruby 引入这种谓词方法风格，纯粹是作为人类之间的一种交流工具。实际上，解释器要能看到这个问号，需要做更多的工作。为什么这里会有这个问号？因为它读起来太舒服了。if user.admin?，这是一个非常人性化的短语，但还有更好的。你可以把这个反过来。你可以把要执行的语句放在条件语句之前。你可以写 user.upgrade，比如说你在调用一个用户的升级方法，空格，if，空格，user.admin?。我们做这件事，如果那件事是真的，而不是说如果那件事是真的，就做这件事。但还有更好的。这就是为什么我喜欢这个条件语句的例子，因为你可以不断深入。让我们把它反过来。user.downgrade if !user.admin，这是一种典型的写法。Ruby 认为那个感叹号是行噪声。为什么我们有 if 然后又有一个感叹号，这太丑了？我们可以写 user.downgrade unless user.admin?。

Lex Fridman

那太棒了。

DHH

对我来说，这 encapsulates (封装) 了 Ruby 通过一种只为服务于人类读者和作者的模糊性所带来的不可思议的美。我们刚刚讨论的所有这些语句，对电脑来说都是一样的。它会编译成相同的 C 代码，编译成相同的汇编代码。没有任何区别。事实上，这只会让编写解释器变得更难。但对于能够选择语句在条件语句之前还是谓词方法在之后的人类来说，这简直太不可思议了。它有时读起来就像诗歌。

Lex Fridman

同样不可思议的是，一个语言设计者创造了这一切。Guido van Rossum 也是。就像一个人要做这些极其困难的决定，因为你必须考虑所有这些如何被解析，你必须考虑成千上万，如果是一种流行语言，那就是数百万使用它的人，以及他们的感受，那个 if 语句的问号对用户来说感觉如何。

DHH

Matz 就是这么想的，因为他开始他的整个使命就基于一个与我听过的几乎所有编程语言设计者所阐述的愿景都不同的前提，那就是他的首要目标是程序员的幸福感。他的首要目标是提供一种便利，让程序员不仅能正确地执行代码，还能在编写和阅读代码时感到愉悦。这个愿景是基于一种对人性根本不同的看法。Matz 和 Java 的设计者 James Gosling 之间形成了鲜明的对比。我想听 James 谈论 Java 的设计。为什么它是那样的？为什么它如此僵硬？他非常直白地回答了，顺便说一句，我真的很欣赏这一点，而且我认为 Gosling 在 Java 上做得非常出色，但他对人性的看法相当黑暗。

他的人性观是，程序员平均来说是愚蠢的生物。他们不能被信任使用复杂的编程语言，因为他们会搬起石头砸自己的脚或手。而对于一家中等保险公司的区域开发办公室来说，编写需要持续 20 年的代码，这会有点不方便。现在，这实际上是一种非常 Thomas Sowell 式的关于人类能力有限的观点，我在晚年才开始欣赏。但这也是一种对程序员非常令人沮丧的看法，即有些程序员就是太笨了，无法欣赏代码的诗意。他们太无知了，学不会如何写好它。我们需要给他们一个沙盒，让他们在里面不会伤到自己太多。

Matz 走了完全相反的道路。他相信人性，相信程序员有无限的学习和进步的能力，以至于他愿意把陌生人放在与自己同等的水平上。这是我真正欣赏 Ruby 的第二部分。Ruby 允许你扩展基类。你知道我们刚才谈到 5.times 是一种迭代语句五次的方式。那个 5 显然是一个基类，一个数字。你知道吗？你可以在上面添加自己的方法。我大量地这么做了。在 Rails 中，我们有一个叫做 Active Support 的东西，它基本上是我用来编程 Web 应用的 Ruby 方言。我给你举个例子。我给数字添加了一个叫做 days 的方法。所以如果你写 5.days，你就会得到五天的秒数，因为秒数是我们设置缓存过期时间等东西的方式。所以你可以说缓存 expires in 5.days，然后你就会得到……

Lex Fridman

那不错。

DHH

……五乘以 24 乘以 60 乘以 60 的结果，或者不管数学是怎么算的，对吧？非常人性化可读。在一种常规的编程语言中，你会写出秒数，然后在上面加一行小注释说“这代表五天”。在 Ruby 中，你可以写 5.days。但更棒的是，Matz 并没有想出这个。Matz 不需要 5.days。我需要，因为我需要让缓存过期。Matz 允许我用我自己的章节来扩展他的故事，而且是平等的地位，以至于一个 Ruby 读者无法区分 Matz 写的代码和我写的代码。

他信任我这个来自丹麦、他素未谋面的陌生人，去摆弄他美丽的故事。这种信任程度基本上是闻所未闻的。我知道有其他编程语言允许用宏 (macros) 等方式做类似的事情，但没有一个能像 Ruby 那样。没有一个能像 Matz 那样，带着对人性的明确愿景和信任来做这件事。这与 Java 的理念是完全对立的。

Lex Fridman

是的，从我的审美角度来说，你描述 5.days 的方式对我来说真的非常愉快。我可以想象自己一个人，睡眠不足，就写着那个。这很简单。你可以用带注释的长方式写，可以写多行，你可以……现在有了 AI，我肯定它能正确生成，但那种简单中有一种非常愉快的东西。我不确定那是什么，但你说得对。那里有一种美好的感觉。我想我们还会从各种哲学角度谈论幸福，但那正是幸福的组成部分。那一点点美好的感觉。

DHH

没错。这就是将一个概念压缩到其纯粹本质时产生的美好感觉。你无法从那个语句中拿走任何多余的东西。

Lex Fridman

但是，我也想稍微反驳一下，因为这不……因为我也写过很多 Perl，只是为了装酷。所以这不完全是关于压缩。

DHH

不，你可以压缩得太过分。Perl golf 就是一种把程序变成人类无法阅读的东西。Perl 的伟大之处在于它比 Ruby 更早出现。Matz 是 Wall 的好学生，是 Perl 的好学生，是 Python、Smalltalk 和 Lisp 的好学生。他从所有这些先前创造优秀编程语言的尝试中汲取灵感，并真正地将最好的部分编辑整理出来。所以他能够从教训中学习。但我发现 Ruby 的不可思议之处在于，现在是 2025 年，Ruby 已经被开发了 30 多年，而基本上最初的草稿仍然是我们现在使用的 90%。

无论 Matz 在哪里写下 Ruby 的初始版本，那里似乎都有一种神圣的灵感，它超越了时间，以至于至今无人能及。这是我总是觉得很有趣的另一件事。我普遍相信有效市场理论，即如果有人想出了更好的捕鼠器或更好的主意，其他人最终会模仿他们，以至于原来的捕鼠器可能甚至不再被记住。但没有人能够复制 Ruby 的那种精髓。他们借鉴了一些元素，这完全没问题，但 Ruby 在这些指标上，在这种对人性和程序员的信任上，仍然比其他所有人都高出一筹。

Lex Fridman

我们还应该说，完美的编程语言也许是那个指标，但成功的语言又是另一回事，这两者往往不同。Brendan Eich 创造 JavaScript 的故事有一种奇妙之处。JavaScript 征服世界的方式有一种真正的美感。我最近有机会去亚马逊丛林，我最喜欢做的事情之一就是看着蚂蚁占领任何东西，所有东西。那就像一个很好的分布式系统。它很混乱，看起来没有秩序，但它就是能工作，以及它的运行机制。

DHH

“差即是好”(Worse is Better)。这实际上是软件开发和其他领域的一种模式的名称，也是 Linux 的模式。Linux 在当时质量上明显比 Minix 要差，后者更像是大教堂式的，而不是那种奇怪的集市式的，但它仍然赢了。这其中有某种东西，不完美有时能帮助事物前进。这实际上是我研究过的一个技巧，以至于我现在几乎在我所有的开源项目中都采用了它。我确保在我发布任何新东西的第一个版本时，它都有点问题。

Lex Fridman

是啊，那太棒了。

DHH

但 Ruby 在某种程度上，或者至少曾经是，有点不同。并非在所有方面。Matz 对语言的精神和设计把握得恰到好处。但 Ruby 的最初几个版本非常慢。Ruby 能既美观又高效且快速，是花了数百年的人力年才达到的。

元编程 (Metaprogramming)

Lex Fridman

我们应该说，让你爱上这门特别的编程语言的东西是元编程 (Metaprogramming)。

DHH

是的。那将我们刚才谈到的所有元素都提升到了一个全新的高度。我来简单解释一下元编程。

Lex Fridman

好的，请讲。

DHH

元编程本质上是 5.days 的一个版本。你可以在语言中添加关键词。Active Record 是 Rails 中与数据库通信的部分。这是一个系统，其中数据库中的每个表都由一个类来表示。所以，如果我们再次以用户为例，你写 class User < ActiveRecord::Base，然后你可以写的第一行是这个：我希望我的用户有很多帖子或者有很多评论。让我们这样做。我们正在做一个用户可以发表评论的系统。下一行就是 has_many :comments。

现在你已经在用户和评论之间建立了一种依赖关系，这将为你提供一系列的访问和工厂方法，让用户能够拥有评论、创建评论、更新评论。仅凭那一行，has_many 看起来就像一个关键词。它看起来就像是 Ruby 语言的一部分。这就是元编程。当 Rails 能够在你定义一个类的方式中添加这些元素，然后那段代码会运行并给用户类添加一堆方法时，那就是元编程。

当元编程以这种方式使用时，我们称之为领域特定语言 (domain-specific languages)。你拿一种像 Ruby 这样的通用语言，然后为某个特定领域量身定做，比如在对象层面描述数据库中的关系。这是一个早期的例子，你可以写 user has_many :comments，belongs_to :account。现在你建立了一个一对一的关系，而之前我们建立的是一对多的关系。Rails 中充满了各种这样的领域特定语言，有时候它甚至看起来不像 Ruby。你无法识别出 Ruby 的关键词，你只能识别出看起来像是它自己编程语言中的关键词。现在，我再次强调，我知道 Lisp 和其他语言也做这些事情。它们只是用能塞进一门编程语言中的最大量的行噪声来做这件事，而 Ruby 做到了一种你无法区分我的元编程和 Matz 的关键词的程度，而且没有任何行噪声。

Lex Fridman

是啊，我应该说我的初恋是 Lisp。所以有一滴你看不见的眼泪正在慢慢滑落。

DHH

我其实自己从来没写过任何真正的 Lisp。

Lex Fridman

那你怎么能对它评价得这么苛刻呢？

DHH

因为我有两只眼睛，我能看代码，我的审美不允许我走得更远，我知道这是一种局限。我其实应该深入研究 Lisp，因为我发现仅仅是深入研究编程语言的过去，我就学到了很多东西。比如 Smalltalk，我认为 Smalltalk 是一个令人难以置信的实验，它也成功了，但不适合今天的编程环境。

动态类型 (Dynamic typing)

Lex Fridman

我很高兴我们能谈这么多关于 Ruby 的话题，关于什么是优美的代码，什么是优美的编程语言。所以，有一件事，我认为在你刚才的描述中可能是隐含的，也许你也明确指出了，那就是 Ruby 是动态类型 (dynamic typing) 而不是严格类型 (strict typing)。你不仅说过这是一件好事，而且你会为动态类型辩护至死。那种自由是一种需要维护的强大自由。

DHH

这正是 Ruby 之所以为 Ruby 的精髓。这也是为什么我完全不理解为什么有人呼吁 Ruby 增加静态类型，因为对我来说，这是它的基石。你为什么要把它最美丽的语言之一变成一个丑陋得多的东西？这是我对静态类型的主要反对意见之一。它不仅在某些方面限制了你，还让元编程变得更难。我写了很多元编程，我见过在 TypeScript 中做元编程需要付出什么。这实际上是让我下定决心把我参与的一些项目中的 TypeScript 移除的原因之一。

我们把 TypeScript 从 Turbo 中移除了，Turbo 是我们前端框架之一，因为我尝试在 TypeScript 中编写元编程，结果被彻底激怒了。我不想要那种体验，但从审美的角度我也不想要。我讨厌重复。我们刚刚谈到我多么喜欢 Ruby 将所有这些表达式精炼到其本质。

……关于我多么喜欢 Ruby 将所有这些表达式精炼到其本质。你无法移除一个点，无法移除一个字符而不失去某些东西。一旦你选择静态类型，你至少要声明……我知道有办法做隐式类型等等，但让我们就拿一个典型的例子来说。大写的 User，我正在声明变量的类型。小写的 user，我现在正在命名我的变量，等于大写的 User 或者 new User。我已经重复了 user 三次。我没时间搞这个。我的审美也容不下这个。我不想我的 Ruby 被这个污染。现在，我理解人们喜欢静态类型的所有论点。其中一个主要论点是它让工具变得更容易。例如，它让编辑器里的自动补全更容易。它让发现某些类型的 bug 更容易，因为也许你正在调用一个对象上不存在的方法，编辑器可以在你运行之前就捕捉到那个 bug。我不在乎。

首先，我不是用工具写代码，我是用文本编辑器写代码。我是用我的双手把它们从屏幕上凿出来的。我不自动补全。这就是为什么我如此热爱 Ruby，也是为什么我继续迷恋文本编辑器而不是 IDE。我不要 IDE。我希望我的手指必须单独敲出每一个元素，因为这会迫使我留在 Ruby 美丽的世界里。因为一旦输入大量样板代码变得容易，你猜会怎样？你就会有大量样板代码。基本上每一种有很好工具支持的语言，对样板代码的容忍度都高得多，因为想法是，“反正你又不是自己打的，你只是自动补全的。”我完全不想要那个。我想要的是我工作的基础只是一份文本文件，没有其他任何东西。所以这些东西是相互关联的。有审美部分，有工具部分，有元编程部分。

还有，Ruby 的“鸭子类型”(duck typing) 理念……我不知道你是否听过这个词。它本质上不是关于“如果一个对象是某个类的实例，我能调用这个方法吗？”而是关于“如果这个方法有响应，我能调用它吗？”这方面很像 Smalltalk。你实际上不检查那个类是否有这个方法，这允许你在运行时动态添加方法，做各种非常有趣的事情，这些都是我们在 Ruby 中做的所有美丽的元编程的基础。我不想失去任何这些，我也不在乎那些好处。我看到被反复吹捧的好处之一是，它更容易写出正确的软件。你的 bug 会更少。你的空指针异常会更少，所有这些东西都会更少。是的，但我没有遇到这些问题。这根本就不是我标准操作模式中会出现的事情。我不是说我没有 bug，当然有，但我用单元测试、集成测试来捕捉那些 bug。

这些预防措施可以捕捉到逻辑错误，即那些可以编译但却是错误的 bug，以及那些无法编译的东西。所以我从未被吸引到这个世界，部分原因是我从事的是某一类系统的工作。我完全接受这一点。如果你在写有五百万、一千万、五千万行代码的系统，有成百上千甚至上万的程序员在工作，我完全接受你需要不同的方法。我反对的是这样一种观点：对于一个有一千万行代码、十万个程序员在上面工作的代码库来说是正确的东西，也应该是我在我的卧室里用来创建 Basecamp 的东西，因为我只是一个人。这完全是无稽之谈。在现实世界中，我们会知道这毫无道理。就像你不会开着你的帕加尼去 Costco 买菜。那是一辆不适合干这个活的车。它就是没有空间，你也不想弄脏那些漂亮的座椅。你不想做任何那些事。

我们知道，在某些领域非常好的东西并不适用于所有领域。在编程语言方面，我们似乎忘记了这一点。现在，公平地说，我也可能有一点忘记这一点的名声。当我第一次学习 Ruby 时，我对这门编程语言爱得神魂颠倒，以至于我几乎无法想象会有人选择任何其他编程语言来写 Web 应用。我当时以一种十字军东征的精神参与了 Ruby on Rails 的布道，就像是，“我只需要教给你福音。我只需要给你看我们刚才谈到的那个条件代码，你就会在尖锐的论证下皈依。”现在，我明白了那不是正确的方式，部分原因在于程序员的思维方式不同。我们的大脑构造不同。我的大脑完美地适配于 Ruby，完美地适配于一种动态鸭子类型的语言，一种我可以用文本编辑器凿出代码的语言。

扩展性 (Scaling)

其他人需要 IDE 的安全感。他们想要那种除非你正确调用方法否则类就无法编译的安全感。我已经开始接受这一点了，但大多数程序员并没有。他们仍然停留在“我喜欢静态类型。因此，静态类型是创建可靠、正确系统的唯一途径”的思维定势中。坦率地说，面对堆积如山的相反证据，说出这样的话简直是令人难以置信的愚蠢。这也是我如此喜爱 Shopify 作为 Ruby on Rails 旗舰应用的原因之一。Shopify 的规模是大多数程序员永远无法企及的。在黑色星期五，我想 Shopify 每秒处理了一百万个请求。那不是一百万个图片请求，而是动态请求，它们流经商业管道。我的意思是，Shopify 运行着该死的互联网上大约 30% 的电子商务商店。所有商业活动中的很大一部分都通过 Shopify 运行，而它运行在 Ruby on Rails 上。所以 Ruby on Rails 能够扩展到那个级别，而没有在其所有功能中使用静态类型。

现在，我知道他们在某些方面做过一些实验，因为他们确实遇到了一些动态类型会遇到的限制。顺便说一句，其中一些你用动态类型遇到的限制，其实只是你在写了 500 万行代码时会遇到的限制。我想 Shopify 的单体应用大约有 500 万行代码。在那种规模下，任何东西都会出问题，因为你正处于人类使用编程语言能力的极限。部分区别在于 Ruby 是一种非常简洁的语言，那 500 万行代码，如果用 Go 或者 Java 写，可能会是 5000 万或者 2500 万。现在，这可能会缓解一些你在大型系统上与许多程序员一起工作时遇到的问题，但它肯定也会加剧这些问题；试着去理解 2500 万行代码吧。

Lex Fridman

所以说这东西确实能扩展。它不能扩展是一个持续存在的迷思，Shopify 和其他公司，但我觉得 Shopify 是个很好的例子。顺便说一句，我爱 Shopify，我也爱 Toby。

DHH

你得请 Toby 来上节目。我今天早上刚和他聊过。

Lex Fridman

当然。他是个很聪明的人……我有机会在沙漠里和他待过一段时间，我忘了，是在犹他州。他真是个很聪明的人。


















Shopify.com/lex

























长期以来一直在支持这个播客。我想 Toby 可能都不知道他们赞助了这个播客。我的意思是，这是一家大公司，对吧？

DHH

这是一家巨大的公司。我想大概有不到 10,000 名员工，市值 1200 亿美元，每个季度的商品交易总额 (GMV) 达到 2500 亿美元。

Lex Fridman

但他还是很关注细节。

DHH

他非常关注。关于 Toby 有个有趣的故事，Toby 在 2000 年代中期是 Rails 核心团队的成员。Toby 自己……

Lex Fridman

真的吗？

DHH

……写了 Active Merchant，这是一个创建商店的框架。他写了 Shopify 至今仍在使用的 Liquid 模板语言。他对 Rails 生态系统做出了巨大的贡献，而且他还是公司的 CEO。这对我来说非常鼓舞人心，因为它与我喜欢做的事情截然相反。我喜欢大部分时间都用自己的双手凿代码，而他管理着一个近万人的公司。那是一个毫不夸张地说，世界商业都依赖于它的重要性，我甚至无法开始理解。然而，我们可以在计算机科学和程序开发的许多基本问题上达成共识。这是一种动态范围，能够涵盖 Rails，它既是刚起步的一个开发者的绝佳工具……他甚至不完全了解所有事情，正处于那种 PHP 在 90 年代末会很适合的水平。因为，是啊，我大概能把东西上传到 FTP 服务器之类的。

Rails 的复杂性确实比那更高，但它的发展空间也大得多。这条跑道一直延伸到该死的 Shopify。这大概是我能为动态范围提出的最有说服力的论据了，我们能做到很多。即便如此，Shopify 当然也是个例外。我在写 Rails 时，并不会把 Shopify 看作主要目标，我想的是单个开发者。实际上，我确实会考虑 Shopify，但不是现在的 Shopify。我想的是 Toby 当时在写 Snow Devil 时的 Shopify，那是他创建的第一个销售滑雪板的电子商务商店。那是 Shopify 出现之前的 Shopify，他完全靠自己创建的。而那之所以成为可能，是因为 Ruby on Rails 不仅仅是关于优美的代码，它同样也关乎生产力。它同样关乎单个程序员所能产生的影响。

他们可以构建一个能将整个系统装在自己脑海里并能推动其前进的系统，以至于你可以从一个开发者坐下来开发某个东西……而那个东西就是 Shopify，然后它变成了今天的样子。当我们谈论和比较编程语言时，我们常常在很晚的阶段进行比较。比如，对于 2009 年的 Twitter 来说，当它已经取得巨大成功时，哪种编程语言更好？Twitter 最初是在 Ruby on Rails 上启动的。后来他们遇到了一些扩展性问题，当时闹得沸沸扬扬。我想他们最终用其他语言重写了它，顺便说一句，我认为这对于 Ruby on Rails 来说是最好的广告，因为在他们转换之后，基本上十年内什么都没发生，几乎是零创新。部分原因在于他们正在进行一个漫长的转换过程，而所有早期的成功，部分是因为他们有快速改变和适应的敏捷性。这就是创业公司所需要的。这就是 Shopify 所需要的，也是 Twitter 所需要的。

这就是每个人都需要的，也是 Ruby on Rails 的首要任务，确保我们不失去这一点。因为当开发工具和编程语言由大公司驱动时，经常会发生的情况是，它们会反映出这些公司的组织结构图。React 和使用它所需的一切，在某种程度上反映了 Meta 是如何构建 Facebook 的。因为当然是这样，因为它当然是那个过程的产物。我不是说 React 不是一个好工具，不能被小团队使用，当然可以，但它诞生的背景与像 Ruby on Rails 这样的东西非常不同。

Lex Fridman

让我插一句……因为我想我们可能会经常回到 Shopify 并赞美它，只是一个个人说明。这个播客的赞助商，以及想成为赞助商的，远比我可能有的要多。对我来说，不去在乎这些，能够赞美人们，是非常非常重要的。我赞美人，我赞美公司，我不在乎他们是否是赞助商。我真的不在乎。我只是想把这一点说得很明确，因为我们会继续说关于 Shopify 的好话。我不在乎，停止赞助，这对我来说真的不重要。是的，我只是想明确这一点。但回到关于 Twitter 和 Shopify 的扩展性问题上，你能给我解释一下 Shopify 在 JIT 方面做了什么吗？他们为了扩展这个东西，必须尝试做什么，因为那是一个相当不可思议的故事，对吧？

DHH

是的。Shopify 对整个 Ruby 生态系统，不仅是 Rails，尤其是 Rails，做出的巨大贡献之一就是 YJIT。YJIT 是他们为 Ruby 开发的编译器，它让所有东西都变得更有效率。在 Shopify 的规模下，即使是挤出 5%、10% 的 Ruby 开销和执行时间改进，也是一件大事。现在，Shopify 并不需要 YJIT。Shopify 已经运行在 Ruby 的初始版本上，那个版本比我们今天的版本慢 10 倍，如果你回顾一下 Toby 可能开始使用的 Ruby 1.8.6，就像我开始使用的一样。那足以推动 Shopify 发展到今天的规模。很多关于扩展性的讨论都迷失在一个未能区分两件事的失败中。扩展性是我们谈论的一个整体，但实际上它内部有多个部分。一个是运行时性能、延迟，即你执行单个请求的速度有多快？它能否快到用户注意不到？如果你的 Rails 请求需要一秒半来执行，用户就会注意到。你的应用会感觉又慢又卡。

你必须把响应时间降到，比如说，至少 300 毫秒以下。我喜欢把 100 毫秒作为我的延迟目标。那种性能，即你能从单个 CPU 核心中挤出多少那种延迟的性能？这告诉你单个请求的成本会是多少。但是，你是否能处理每秒一百万个请求，就像 Shopify 现在正在做的那样，如果你有一台机器能做每秒一千个请求，你只需要 X 台机器就能达到一百万。你实际上会发现，当涉及到编程语言时，它们在这方面都是一样的。它们都可以在很大程度上，优美地水平扩展，你只需要增加更多的机器。扩展一个 Shopify 的难点通常不在于编程语言，而在于数据库。这实际上是 Shopify 现在面临的挑战之一，即如何处理他们运营规模下的 MySQL？什么时候你需要迁移到其他数据库以获得全球性能？所有这些事情。关于扩展 Ruby 的问题是经济问题。

如果我们花这么多钱在应用服务器上，如果我们能从 Ruby 中多挤出 5% 的性能，那么我们就可以省下 5% 的服务器，这就可以体现在预算中。现在，这种分析基本上可以得出一个结论：Ruby 是一种奢侈的语言。它是一种奢侈品，在我看来是最高级的奢侈品。它是编程语言中的可可·香奈儿 (Coco Chanel)，不是每个人都买得起的，我这是以最好的方式说的。互联网上有些应用，每个请求的价值非常低，你负担不起使用像 Ruby 这样奢侈的语言来编程。你只能用 C、Go 或其他一些低级语言，或者 Rust——说到行噪声——来凑合。

Lex Fridman

那就像是语言中的二手店。

DHH

正是如此。你需要的，你需要一个非常低的层次来做这件事。你负担不起用一种奢侈的语言来构建它。但 Shopify 不是这样。即使在 2004 年的 Basecamp 也不是这样。99% 的 Web 应用也都不是这样，因为 99% 的 Web 应用的主要成本构成，不是 CPU 核心，而是 Web 核心，是人力核心。是人类理解和参与系统的能力，是他们的个人生产力。有一次有人第 400 次说，“哦，如果你从 Ruby 换成更快的语言，你就能省一大笔钱。”我计算了一下，当时……我想我上次做这个计算是差不多十年前了，我们大约 15% 的运营预算花在了 Ruby 应用服务器上。所以对我来说，要想把我的业务成本降低七个百分点，我得选择一个快两倍的东西。那相当难。

相比之下，如果 Ruby 和 Ruby on Rails 比其他东西的生产力哪怕只高出 10%，我能带来的改变就会大得多，因为提高单个程序员的生产力实际上要重要得多。这就是为什么人们对 AI 如此兴奋。这就是为什么他们对硅谷一个年薪 30 万美元的程序员现在能做三到五个人的工作而感到震惊，至少理论上是这样。我实际上还没有在实践中完全看到这一点。但我们假设这个理论是正确的，如果不是现在，那么在六个月后，那将是一件大事。这比你是否能从 CPU 中多挤出几个周期要重要得多，当涉及到这类商业应用时。如果你在做像 Tim Sweeney（你请过的嘉宾）那样的虚幻引擎渲染工作，是的，他需要非常仔细地考虑所有这些细节。Nanite 引擎不能在 Ruby 上运行。它永远不会，它也不是为此而设计的，没关系。这类商业应用绝对可以。

而且，人们现在对 AI 感到兴奋的一切，那种额外做更多事情的能力，正是我们在 2000 年代初对 Ruby 感到兴奋的原因。那是因为我看到，如果我们能把人类程序员的生产力哪怕提高 10%，我们就能用少得多的成本做多得多的事情。

编程的未来

Lex Fridman

我们可能会为此争论，但我真的很喜欢和 AI 一起工作，和 AI 合作。我认为你想让 AI 生成的代码是人类可读、人类可解释的。如果它生成的是那种 Perl golf 式的代码，那就不是合作了。所以它必须说人类的语言……这不仅仅是你在用英语写提示，你也希望用人类可解释的语言，比如 Ruby，来阅读它的回应，对吧？所以这对 AI 实际上也是有益的。因为你说过，对于你这个雕塑家，这个精英的可可·香奈儿 (Coco Chanel) 式的雕塑家，你希望用你那花哨的键盘，用你自己的手指，亲自敲下每一个字母。但 Ruby 的好处也体现在，一旦代码是由 AI 写成的，而你实际上是用自己的手指在做编辑部分，因为它是人类可解释的，所以你能和它互动。

DHH

我非常喜欢这个范式，实际上是 Elon 在你的一个节目中说的，当时你们在讨论 Neuralink，他说 Neuralink 增加了你和机器之间的带宽。语言，无论是口头的还是书面的，都是非常低带宽的。如果你要计算我们坐在这里能交换多少比特，那是非常慢的。Ruby 有更高的通信带宽，每个字符所揭示、传达的概念比大多数其他编程语言要多得多。所以当你和 AI 合作时，你想要非常高的带宽。你希望它能和你一起生产程序，无论你是否让它写代码，你们俩都能很快地理解。而且你可以把一个宏大的概念、一个宏大的系统压缩成少得多的部分，你们俩都能理解。现在，我实际上也喜欢和 AI 合作。我喜欢凿我的代码，我使用 AI 的方式是在一个单独的窗口里。我不让它驱动我的代码。我试过。我试过 Cursors 和 Windsurfs，但我不喜欢那种写作方式。

我不喜欢那种写作方式的原因之一是，我能真切地感觉到能力正从我的指尖流失。那种与材料的直接接触感消失了。我感受最深的一次是，当我切换到 Linux 时，我做了一个叫做 Omakub 的 Ubuntu 定制版。它全是用 Bash 写的。我以前从来没有用 Bash 写过任何像样的代码，所以我用 AI 合作，和我一起写了很多 Bash，因为我需要所有这些。我知道我想要什么，我可以用 Ruby 表达出来，但我认为通过 Bash 来过滤它是一个有趣的挑战。因为我当时在做的是设置一台 Linux 机器，这基本上就是 Bash 的设计初衷。这是一个很好的限制。但我发现自己一遍又一遍地向 AI 索要同一种表达条件语句的方式，比如在 Bash 中。因为不亲自打字，我就学不会。我在使用它，我得到了我想要的表达方式，但我没有学会它。我有点害怕了。

我有点害怕，这是学习的终结吗？如果我不打字，我还会学习吗？对我来说，我重新审视这个问题的方式是，我不想放弃 AI。作为一名程序员，查阅 API、获得第二意见、起草初稿，这是一种好得多的体验，但我必须自己打字，因为你是用手指学习的。如果你在学弹吉他，你可以看任意多的 YouTube 视频，但你学不会吉他。你必须把手指放在琴弦上，才能真正学会那些动作。我认为这和编程有相似之处，编程的一部分必须通过实际打字来学习。

Lex Fridman

我真的觉得这很有趣。听着，我大脑的一部分百分之百同意你，另一部分不同意。我认为 AI 应该在学习的循环中。现在的系统做不到这一点，但我认为 Cursor 完全有可能做到，基本上强迫你输入某些东西。所以如果你设置了学习模式……我不想放弃 AI。我认为“感觉编程”(vibe coding) 是一种技能，所以对于有经验的程序员来说，很容易把“感觉编程”看作是一种不值一提的东西。

DHH

我同意，我不会轻视它。

Lex Fridman

但我认为你需要开始培养这种技能，并开始弄清楚，如何防止能力从你的指尖和大脑中溜走？你如何与另一种技能并行发展这种技能？我不知道。但我认为这是一个有趣的谜题。我认识太多非常厉害的程序员，他们就是不碰 AI，因为它目前还有点笨。

DHH

是的。它有点太慢了，这其实是我的主要问题。它在某些方面有点笨，但在另一些方面有点太慢了。当我使用 Claude's Code，也就是 Claude 的终端版本……这其实是我更喜欢的使用方式，我会变得不耐烦。感觉就像回到了代码需要编译的时代，我得去做点别的事情，比如烧点茶，等着代码编译。嗯，我用 Ruby 已经 20 年了，我再也受不了编译等待了，所以有这方面的原因。但我认为对我来说更关键的方面是，我真的很在乎能力。我见过即使是优秀的程序员，一旦他们放下键盘会发生什么，因为即使在 AI 出现之前，这种情况也会在人们升职后发生。大多数在大公司工作的优秀程序员，都会停止每天写代码，因为他们有太多的会议要参加，有太多的其他事情要做，他们不可避免地会与编程脱节。

这并不意味着他们会忘记一切，但如果你不亲自动手，你就会与它脱节。没有别的办法。我不想要那样，因为我太喜欢编程了。这不仅仅是关于结果。这是理解的关键，对于喜欢编码的程序员来说，编程不仅仅是为了得到程序。那可能是经济价值。但不是唯一的人类价值。人类价值同样在于表达。当有人坐下来用吉他弹奏《通往天堂的阶梯》(Stairways to Heaven) 时，那首歌已经有了完美的录音，可以永世流传。你可以直接在 Spotify 上播放，你实际上不需要自己弹。乐趣在于自己驾驭吉他。一个程序员，我作为一个程序员的乐趣，在于自己敲代码。如果我提升自己，让自己脱离编程，我就会把自己变成一个项目经理，一个我前几天写的“一群 AI 乌鸦”的项目经理。如果我不在乎自己写代码，只想要结果，我整个职业生涯都可以成为一个项目经理。

如果我不在乎自己写代码，只想要结果，我早在 20 年前就可以成为项目经理了。我最初接触编程就是因为我只想要结果。然后我爱上了编程，现在我宁愿退休也不愿放弃它。当然，这并不意味着你不能鱼与熊掌兼得。我做过一些“感觉编程”(vibe coding)，当时我并不在乎是不是我自己在演奏。我只是想看看我脑海中的一个想法。我想看到一些东西，那没关系。我也整天都在用 AI。事实上，我已经到了这种地步，如果你把它从我身边拿走，我就会觉得，“天啊，我们现在还怎么在网上查东西？Stack Overflow 还在吗？论坛还是个东西吗？我整天遇到的这些问题，我怎么找答案？”我不想放弃 AI。事实上，我想说，我喜欢使用 AI 的方式，让我每天都变得更聪明，因为我用 AI 来让它给我解释事情。

即使是那些我有点不好意思在谷歌上搜索的愚蠢问题，AI 也非常愿意给我一个“给五岁小孩解释”(ELI5) 某个我早就该知道但实际上不知道的 Unix 命令的解释。对不起，你能给我解释一下吗？现在我知道了。所以，在我整天和 AI 一起工作的一天结束时，我变得更聪明了一点，大概 5%。抱歉，不是 5%，也许是半个百分点，这会随着时间复利。但当我在 Omakub 项目上工作，并试图让 AI 为我驾驶时，我也看到了，我感觉在一天结束时我可能变笨了半个百分点。

Lex Fridman

好的，你说了许多有趣的事情。首先，让我们从最基本的事实说起，那就是问愚蠢的问题。如果你去 Stack Overflow 问一个愚蠢的问题，或者读别人的愚蠢问题及其答案，那里充满了评判。AI，有时甚至到了过分的程度，毫无评判。它通常会说：“哦，这是个很好的问题。”

DHH

简直是过分了。

Lex Fridman

是啊。哦，那太棒了。是的。我的意思是，这对学习太有帮助了。它是一个极好的学习工具，我也会想念它的。它基本上是一个很棒的搜索引擎，可以帮你了解一门特定编程语言的各种细微之处，尤其是当你不太熟悉它的时候。或者你可以加载 API 文档，它对学习真的很有帮助。对我个人而言，我的意思是，从幸福感的角度来说，它让我对编程更有热情了。我不知道具体是什么原因。部分原因是……我真的很抱明，Stack Overflow 是一个不可思议的网站，但那里有一种负面情绪。有一种评判。能有一个啦啦队长在我身边，对我说：“是啊，那是个好主意。”这很令人兴奋。我会说：“不，那不对。”我会纠正 AI。AI 会说：“你完全正确，我怎么没想到呢？你准备好了。”我心想：“天啊，我这就像有一个非常积极、非常聪明、并且能挑战我思考的朋友。”

而且，即使我从不使用它生成的代码，我也已经是一个更好的程序员了。但实际上更深层次的是，出于某种原因，我玩得更开心了。这是一件非常非常重要的事情。

DHH

我喜欢把它看作一个结对程序员，正是因为这个原因。结对编程 (Pair programming) 在 2000 年代开始流行，你会看到两个程序员坐在一台机器前，互相传递键盘。一个程序员在驾驶，负责输入。另一个程序员基本上就是坐着看代码，提出改进建议，查阅资料。那是一种非常有趣的动态。不幸的是，我是一个内向的人，所以那种事我大概只能做五分钟就想跳桥了。所以对我来说，把它当作全职工作是行不通的，但 AI 让我能够一直拥有这种体验中最好的部分。现在，我认为你说的它让事情变得更有趣这一点很有意思。我之前没有想过，但它让我觉得再次成为一个初学者变得更有趣了。它让第一次成功地学习 Bash 变得更有趣了。

当然，我走了弯路，让它为我写了所有代码，然后意识到我学到的东西远没有我希望的那么多。一旦我开始自己把它敲出来，情况就不一样了。但它给了我信心，让我觉得，你知道吗？如果我需要自己做一些 iOS 编程……我大概有六年没碰过了，上次涉足还是六年前。我从来没有真正构建过任何实际的东西。我现在非常有信心，我可以和 AI 坐下来，一周之内就能在应用商店里上架一个东西。如果没有 AI 这样一个结对编程的伙伴，我不会有这种信心。我实际上不怎么用它来写 Ruby 代码。我偶尔试一下，会感到印象深刻，比如，“哦，它把这个东西做对了，这真是了不起，而且做得相当不错。”然后我再问两个问题，我就会想，“哦，好吧，如果你是我的初级程序员，我就会开始敲手指说，‘你得加把劲了。’”

当然，最棒的是，我们只需要再等五分钟。Anthropic 的 CEO 似乎认为，到今年年底，90% 的代码都将由 AI 编写。我对这一点持相当大的怀疑态度，但我对编程可能最终会变成一种“骑马”的前景持开放态度。一种我们为了娱乐而做的事情，不再是洛杉矶的交通工具。你不会再骑马上马鞍去杂货店，用马鞍袋从 Whole Foods 买东西。那已经不是现在的事情了。这可能是编程的未来，完全有可能。我也不在乎。尽管我们有所有最好歌曲的精彩演绎，正如我所说，仍有数百万人喜欢弹吉他。它可能不再像以前那样有那么大的经济价值。我认为这一点我相当确信，我们可能已经见证了它的顶峰。

现在，我理解这个悖论，当某物的价格下降时，实际上它的总使用量会上升，用于该活动的总支出也会上升。这也可能发生。但我们现在看到的是，很多大公司，很多大公司，都不像五年前那样招聘了。他们不预期会需要更多的程序员。有争议的是，Toby 实际上在 Shopify 内部发布了一份备忘录，要求每个考虑招聘的人都问一个问题：“这能由 AI 完成吗？”现在，他在这件事上比我走得更远。我看着一些代码和……我会想：“我很乐意更多地使用 AI，我也看到它如何让我们更有效率。但它还没有达到那种程度，让我可以直接说：‘哦，我们有这个项目，让我把它交给 AI 代理，它就会自己去做了。’”

Lex Fridman

但我们得老实说，你就像一个克林特·伊斯特伍德 (Clint Eastwood) 式的牛仔角色，骑在马上看着汽车来来往往。你会说：“嗯……”

DHH

这确实是一部分原因。我认为保持这种谦逊很重要，即你所擅长的东西可能不再是社会所看重的。这在历史上发生过无数次……你可能曾经在制作马鞍方面非常出色。那曾经是很多人关心的事情，因为每个人都骑马。然后突然之间，骑马变成了一种小众爱好，只有少数人关心，远不如以前那么多。这没关系。现在，另一件事是，我有幸做了将近 30 年的程序员。这是一段很棒的经历。我试着这样看待生活，我已经有幸拥有了几十年经济上可行、非常有价值的方式，将我在工作世界中最喜欢的事情——写 Ruby 代码——转化出来。这非常有价值，以至于我能靠它赚取数百万美元，如果明天这一切都结束了，我不应该带着遗憾看待它，而应该带着感激。

Lex Fridman

但你也是一个经验丰富、才华横溢、观点鲜明的人……

Lex Fridman

……才华横溢、观点鲜明的人。所以听你对“马”的未来的看法非常有趣，因为有很多年轻人正在听这个，他们热爱编程，或者对用软件、用 Ruby on Rails 这样的语言创造东西的可能性感到兴奋，现在又有了新的可能。

DHH

但它还能成为一个职业吗？

Lex Fridman

它还能成为一个职业吗？如果一个人真的可以在 AI 的帮助下创造越来越多的东西，他们该如何学习这项技能？这是一项值得学习的技能吗？我的意思是，这对我来说是真正的谜团，因为我认为目前你仍然绝对需要从头开始学习编程，但你如何平衡这两种技能？因为我也有同感，正如我现在所想，有一种可怕的技能流失，在处理某段特定代码时，真的几分钟内就会发生。这很可怕，而驾驶时，当你让汽车为你驾驶时，技能流失得没有那么快。所以这真的让我害怕。当有人走过来问我如何学习编程时，我不知道该给什么建议，因为我认为仅仅使用 Cursor 或 Copilot 来生成代码是不够的。

DHH

这绝对不够。如果你想学习，如果你想变得更好，那就不够。如果你只是变成一个按键猴子，也许你在一秒钟内就能提高生产力，但然后你必须意识到，如果这就是我们整天坐着做的事情，就是不停地按“是，是，是，是，是”，那任何人都能做到吗？是的，那不是一项有市场价值的技能。现在，我总是先对自己，也对别人说，第一条规则是，没人他妈的知道任何事。没有人能预测哪怕六个月后的事情。

人工智能的未来

现在，我们可能正处于 AI 未来炒作的顶峰，因为我们看到了所有的希望，因为其中很多是真实的，很多人都亲身体验过。这种令人难以置信的事情，即硅基物质以一种诡异地让人联想到人类的方式在思考。我实际上想说，对我来说，最大的冲击甚至不是 ChatGPT，甚至不是 Claude，而是 DeepSeek。在本地运行 DeepSeek，看到那个“思考框”，它在其中与自己对话，讨论如何组织回应。我几乎想，这是不是一个噱头？它是不是为了我的利益在表演？但那实际上不是它的思考方式。如果这真的是它的思考方式。好吧，我有点害怕了。它以这种方式思考，简直是不可思议地像人类，但这会走向何方呢？所以在 95 年，我最喜欢的电影之一，我最喜欢的 B 级片之一上映了，《割草人》(The Lawnmower Man)。

Lex Fridman

很棒的电影。

DHH

一部关于虚拟现实的不可思议的电影。成为一个化身 (avatar) 并在 VR 中生活，故事一团糟，但美学、它构建的世界令人难以置信，我当时想，我们离那只有五年了。我现在就要活在 VR 里了。我就会四处漂浮。我就会成为一个化身。这将是大多数人度过大部分时间的地方。那没有发生。30 年过去了，VR 仍然没有到来。它在游戏领域实现了，在一些专门的应用中实现了。我的大儿子喜欢玩《猩猩跑酷》(Gorilla Tag)。我不知道你试过没有。那基本上是最火的 VR 游戏。很棒。它很棒。预测未来真的很难，因为我们就是不知道。然后当你把 AI 考虑进来，即使是最聪明的人也会说：“我不认为我们完全理解这是如何工作的。”

Lex Fridman

但另一方面，摩尔定律似乎在很多很多年里都有效，比如在减小晶体管尺寸方面。Flash 没有占领互联网，但摩尔定律奏效了，所以我们不知道 AI 会是哪一种。

DHH

它就是它。这也是我发现如此迷人的地方，我忘了是谁做的那个演讲，但 Web 社区里有人做了一个关于飞机历史的精彩演讲。从莱特兄弟在 1903 年左右飞行，到 40 年后你有了喷气式飞机，短短四十年里取得了令人难以置信的进步。然后到了 56 年，我想是，波音 747 的前身设计就完成了，然后基本上从那以后就没什么变化了。自 50 年代以来，飞行体验只有一些微小的调整和改进。不知何故，如果你要预测飞行的未来，你坐在 42 年，你见过莱特兄弟在 03 年飞行，你看到喷气式发动机出现，你会想：“再过二十年我们就要飞向星辰了。”

我们会发明超超音速飞行器，两小时就能环游地球，然后那没有发生。它到顶了。这就是预测未来如此困难的原因。我们可以在当下感到非常兴奋，因为我们正在一张图表上画一条穿过早期几个点的线，看起来那些早期的点就是一路向右上方去的，但有时它就是会趋于平缓。这也是其中一件事，我们有很多关键基础设施，比如，仍然运行在 COBOL 上，全世界大概只有五个人真正深入地理解它，以至于社会有可能失去它仍然需要的能力，因为它在追逐未来。

COBOL 至今仍在。这是我想到编程时的一件事。Ruby on Rails 现在已经达到了这样一个水平，50 年后，极有可能仍然有大量的 Ruby on Rails 系统在运行。现在，很难预测那个确切的世界会是什么样子，但昨天的天气告诉我们，如果 70 年代的 COBOL 代码今天仍在运行着社会保障系统，而我们还没有找到一个干净利落的方法来转换它，更不用说理解它了，我们当然应该在预测未来时保持谦逊。

我不认为任何在 70 年代写那些 COBOL 代码的程序员会想到，在 2025 年，支票仍然是根据他们当时编码的业务逻辑开出的。但这让我得出了一个关于年轻程序员应该做什么的结论。你无法预测未来。没有人能预测未来。如果你喜欢编程，你就应该学习编程。现在，这会是一个长久的职业吗？我不知道，但什么会是一个长久的职业呢？谁知道呢？不久前我们还以为是蓝领劳动会被抽象化。首先是机器人会接管。然后生成式 AI 出现了，然后所有的艺术家突然都觉得，“天啊，现在所有动画都要由这个来做了吗？所有音乐都要由这个来做了吗？”

他们真的害怕了，现在我看到最新的特斯拉机器人，我想：“哦，也许现在又轮到蓝领工人有麻烦了，因为它如果能那样跳舞，它大概也能修马桶了。”所以没人知道任何事，你必须以这样一种方式为未来定位，即你选择一个职业或道路，即使最终你必须重新学习、重新培训，你也不会后悔你所走的路。这是一个普遍的人生原则。对我来说，我如何看待我参与的所有事业，就是我希望对所有结果都感到满意。

当我们在 37 Signals 开始开发一个新产品时，我会为自己设定一个成功的心理模型，然后想：“你知道吗？就算没人想要这个，我也会有另一次机会去写优美的 Ruby 代码，去探索一个全新的领域，去学习新东西，去构建一个我自己想要的系统，即使别人不想要。”这是何等的幸事，何等的特权。如果很多人想要，那太好了。我们可以支付一些薪水，我们可以让公司继续运营下去。如果它大获成功，那就太棒了。我能影响很多人。

感觉编程 (Vibe coding)

Lex Fridman

我认为一个很大的悬而未决的问题是，你能通过“感觉编程”(vibe coding) 走多远，一个年轻开发者是应该把大部分时间投入到“感觉编程”上，还是从头开始写代码。“感觉编程”，我这里有点顺着这个梗说，但它的意思是，你生成代码，你有一个你想创造的东西的想法，你生成代码，然后你用自然语言提示和手动的方式来修复它。这就是学习过程。你如何修复生成的代码，或者你从头开始写代码，然后让大语言模型帮你补全代码，你应该侧重哪一部分？我认为，为了安全起见，你应该在两者中都找到美、艺术性和技巧，对吧？从零开始，所以你应该花一部分时间完全从零开始写，一部分时间做“感觉编程”。

DHH

如果你有兴趣学习如何编程，你应该花更多的时间从头开始写。不幸的是，你不可能通过看健身视频来变得健康。你不可能通过看 YouTube 吉他视频来学会弹吉他。你必须亲自去弹。你必须亲自做仰卧起坐。编程、理解、学习几乎任何东西都需要你亲自动手。人类不是被设计成仅仅通过远观他人就能将信息吸收并转化为技能的。具有讽刺意味的是，AI 似乎很擅长这一点，但人类不是。如果你想成为一个有能力的程序员，你必须编程。这真的不难理解。现在，我理解这种诱惑，诱惑之所以存在，是因为“感觉编程”可以在当下，特别是在你不熟悉的新领域，用你不熟悉的工具，产生比你做得更好的东西，或者能让你更快地达到目的，但你什么也学不到。

你会以一种肤浅的方式学习，感觉像是在学习，但实际上完全是空洞的卡路里。其次，如果你能通过“感觉编程”来完成，那你就不算是一个程序员了。那样的话，任何人都能做到，这也许是件好事。这基本上和 Access 数据库、和 Excel 发生的事情一样。它让会计师有能力成为软件开发者，因为工具变得对他们如此触手可及，以至于他们可以构建一个模型来预测公司下周的表现，而在 Excel 出现之前，这需要一个程序员。现在，不需要了，因为他们可以自己做。通过编程，非程序员能够以一种我觉得非常棒的方式探索他们的想法，但这并不能让你成为一个程序员。

Lex Fridman

我同意你的看法，但我想为我们俩都可能是错的留出空间。例如，“感觉编程”(vibe coding) 实际上可能是一种技能，如果你训练它，并且我们把修正的步骤，即迭代修正，也包含在内，那么如果你在这方面变得非常出色，你可能会超越那些从头开始写代码的人，你可能会想出真正创新的东西，尤其是在历史的这个时刻，当大语言模型还不够聪明，无法创造出超级新颖的东西和完整的产品，但它们正在逐渐接近那个水平。所以，如果你现在投入时间成为一个非常优秀的“感觉编程”者，也许这是正确的选择。如果它确实是一种技能，我们有点把“感觉编程”当成一个梗，就像坐享其成一样，但如果你认真对待它，成为一个有竞争力的“感觉编程”者，并擅长驾驭 AI 的浪潮，擅长编辑代码的技能，而不是从头开始写代码，那么从长远来看，你实际上可能会走得更远。

也许编辑和从头开始写是根本不同的任务，如果你认真地将其作为一种技能来发展。我明白了。对我来说，这是一个悬而未决的问题。我只是觉得，我个人，当然你在另一个层次上，但就我个人而言，我不太擅长编辑不是我写的代码。那是一个不同的……

DHH

没人擅长。

Lex Fridman

这一代人没人擅长，但也许那是一种技能。也许如果你能和 AI 保持同步，因为 AI 有一种一致性。它就像一个风格和结构都一致的结对程序员。再加上你自己的提示，你可以控制你写的代码的类型。我的意思是，这完全可能是一种技能。

DHH

那是提示工程师 (prompt engineer) 的梦想。我认为那完全是痴人说梦。我不认为存在不擅长写作的优秀编辑。我写过几本书，也和几位专业编辑合作过。他们并非都写出了自己的伟大著作，但他们在某些方面都是优秀的作家。如果你自己不知道怎么做，你就无法给别人指点。对于一个编辑来说，如果他们自己无法解决问题，就很难发现问题所在。成为一名优秀编辑的能力，是你成为一名优秀实践者的回报。你必须先成为一个实践者。现在，这并不是说“感觉编程”、提示工程无法产生完全成型、令人惊叹的系统，甚至很快就能做到。我认为这完全有可能，但那样的话，就不再有任何技能可言了，这也许是最大的回报。

那不正是 AI 的全部承诺吗？就是一切都是自然语言，即使是我笨拙地提出一个问题，也能得到一个优美简洁的回答。这对我来说实际上是一个更有吸引力的愿景，即会有这些特殊的提示工程奇才，他们知道如何恰到好处地“挠痒”AI，让它产生他们想要的东西。AI 的美妙之处在于，一个对 AI 实际工作原理一无所知的人，能够表达出他的想法和愿望，然后 AI 能以某种方式把那一堆杂乱的想法，生产出人们想要的东西。

这实际上一直以来就是编程。通常都是那些不知道如何编程的人，想要程序，然后他们雇佣程序员，给他们一堆乱七八糟的需求描述，然后当程序员交付回来时，他们又说：“哦，不，其实我不是那个意思。我想要别的。”AI 也许能够提供那个循环，如果它能做到极致的话，是的，程序员的数量就不会那么多了，但可以推测，至少在可预见的未来，仍然需要有人去理解 AI 产生的东西是否真的有效。

Lex Fridman

作为一个有趣的案例研究，或者说一个思想实验，如果我想用“感觉编程”的方式来做 Basecamp 或者 HEY，就是你们做的一些产品，瓶颈会是什么？我会在哪个环节失败？

DHH

当我在尝试用“感觉编程”(vibe coding) 来构建真实的东西时，我发现你其实很早就失败了。在目前这个阶段，“感觉编程”能够构建出一个看起来能用的表层，但它在各种方面都有缺陷。有那些显而易见的、被当成梗的方面，比如它会泄露你所有的 API 密钥，用明文存储你的密码。我认为这些最终是可以解决的。它会搞定的，或者至少在这方面会变得更好，但它迷失在自己迷宫中的能力现在非常强。你让它写一些代码，然后你想修改一些东西，很快就会变成一个打地鼠的游戏。

Pieter Levels，他一直在做那个很棒的飞行模拟器，就谈到过，当规模达到一定程度时，它就会不断地自相矛盾。你想修复一个问题，结果却破坏了其他五个地方，我认为这其实是独一无二的人类行为，因为大多数差劲的程序员在面对一定复杂度的领域时就是这样。他们无法在不破坏其他三件事的情况下修复一件事，所以从这个角度看，我实际上觉得这几乎是一个积极的信号。AI 会搞定这个的，因为它现在正走在一条极其人性化的轨迹上。它犯的错误和初级程序员经常犯的错误是一样的。

Rails 宣言：优秀编程语言的原则

Lex Fridman

是的。我们能把视野放大，看看 Rails 的愿景、宣言和信条吗？有哪些东西让一门编程语言、一个框架变得伟大，尤其是在 Web 开发领域？我们谈到了幸福感。

DHH

是的。

Lex Fridman

Ruby 的基本目标。还有什么？

DHH

你看到的是我在 2012 年写下的九条原则。在我们深入探讨之前，我想说，我写下它们的原因是，如果你想让一个社区长久存在，你必须记录下它的价值观和实践。如果你不这样做，最终会有足够多的新人带着他们自己对这个东西应该走向何方的想法进来，如果我们没有一个指引我们做决定的灯塔，我们就会开始摇摆不定，甚至会分崩离析。我认为这是各种机构开始瓦解的关键原因之一。我们忘记了“切斯特顿的栅栏”(Chesterton's fence) 为何存在。我们只是说：“为什么那里有个栅栏？”然后把它拔掉。“哦，原来是用来挡狼的。现在我们都死了。”

糟糕。所以我想把这些东西写下来。如果我们快速地逐一看一下，你谈到了“为程序员的幸福感而优化”。我把这个放在第一位，是为了向 Matz 致敬，这很大程度上是关于接受这样一个事实：在编写优美的代码和我们希望从系统中获得的其他东西之间，偶尔会有权衡。可能会有运行时的权衡，可能会有性能的权衡，但我们仍然会这样做。我们也会允许某种程度的模糊性，而很多程序员默认对此感到不舒服。我在这里举的例子是，在交互式 Ruby Shell 中，你可以玩转这门语言，甚至可以与你的领域模型互动。你至少有两种我发现的方式可以退出。你可以输入 exit。砰，你就退出了程序。你也可以输入 quit。砰，你也退出了程序。

它们做的是同一件事。我们只是同时写了 exit 和 quit，或者说制作那个工具的人同时写了这两个，因为他们知道人们很可能会选择其中一个。Python 是一个完美的对比。在 Python 的交互式协议中，如果你输入 exit，它不会退出。它会给你上一堂该死的课。它基本上会告诉你去读该死的手册。它会说：“使用 exit() 或 Ctrl+D（即文件结束符）来退出。”我觉得，一个是很有温度的，另一个则是很工程师的，我这么说都是从最好的角度出发。Python 是迂腐的。Python 从一开始就声明的价值观是，做某件事最好只有一种，而且是唯一一种方式。Ruby 则完全相反。不，我们想要那种能适应不同人大脑的完整表达方式，以至于这门语言似乎总能猜到他们想要什么。

Lex Fridman

这其中也包含了你所描述的“最少意外原则”(principle of the least surprise)，这是一个很难在语言工程中实现的原则，因为它是一个主观的东西。

DHH

这就是为什么你不能用一种方式来做这件事，这也是为什么我用了 exit 和 quit 的例子。对于一些人来说，“最少意外原则”就是，“哦，exit。这就是我退出提示符的方式。”而对于另一些人来说，则是 quit。我们为什么不两个都做呢？

Lex Fridman

好的，那么“约定优于配置”(convention over configuration) 呢？那是一个很重要的原则。

DHH

那是一个很重要的原则，非常重要。它源于我早期对，尤其是 Java 框架的挫败感。当时，当你为 Java 设置一个 Web 应用框架时，写上成百上千行的 XML 配置文件是常有的事。“哦，我需要这个。我希望数据库用 post_id 作为外键。”“不不不，我希望是 postId。”“哦，不不不，你应该用大写的 PID。”有各种各样的方式可以配置数据库中外键关系的工作方式，但它们都不重要。我们只需要选择一种，然后就可以了。如果我们选择了一种，并且可以依赖它，它就成了一种约定 (convention)。如果它是一种约定，我们就不必去配置 (configure) 它。如果我们不必配置它，你就可以更快地开始做你真正关心的事情。

“约定优于配置”本质上就是采纳这样一个理念：系统应该预先组装好。我不是只给你一盒该死的乐高积木，然后让你去拼一个千年隼号。我给你的是一个成品玩具。你可以编辑，可以修改它。它仍然是用乐高拼出来的。你仍然可以拆下一些部件，换上另一些部件，但我给你的是最终产品。这与大多数程序员喜欢的东西背道而驰。他们喜欢一盒乐高积木。他们喜欢从头开始把所有东西都拼起来。他们喜欢做所有那些根本不重要的小细节决定，而我想把这个层次提升一下，就是，嘿，我不是想剥夺你的决定权。我只是想让你专注于那些真正重要、你真正关心的决定。没有人关心外键是 post_id 还是 postId 或者是 PID。

Lex Fridman

是啊，好的默认值。

DHH

是的。

Lex Fridman

这真是太棒了。你有很多抱负，想用这些积木搭建出某种定制的、前所未有的最美丽的乐高城堡，但在现实中，大多数情况下，为了提高效率，你只需要搭建出基础的东西，然后你的创造力才是在此之上发挥的。

DHH

完全正确，我认为这是信条的一部分，很多使用 Ruby on Rails 的程序员即使不情愿，也会承认这是一件好事。即使他们不真的喜欢，也很难抗拒从头开始用乐高搭建的吸引力。这就是我们程序员的本性。这就是我们当初成为程序员的原因，因为我们喜欢把这些小部件拼凑在一起，但我们可以将这种本能引向技术栈中更有成效的一端。

Lex Fridman

好的。还有哪些其他的原则？

DHH

“菜单是 Omakase (主厨发办)”。这实际上也源于同一个原则，即好的默认值非常重要。如果你看看现在 JavaScript 生态系统中所有错误的地方，你会发现，没有人负责这个菜单。有十亿种不同的菜品，你可以配置出你量身定做的特定组合，但没有人去确保它们都能很好地协同工作。所以你在 JavaScript 生态系统中会遇到各种独特的问题，比如，光是做控制器层就有大概 25 种主流方式，然后与数据库交互的方式也同样多。所以你得到了一个 N 乘以 N 乘以 N 的排列组合，结果就是没有人用同样的东西。

而且如果他们用了同样的东西，也只是用了大概五分钟，所以我们没有积累下任何智慧，没有建立起任何持久的技能。Rails 走了完全相反的道路，它说：“你知道吗？Rails 不仅仅是一个 Web 框架。它是解决 Web 问题的完整尝试。它是解决构建一个优秀 Web 应用所需一切的完整尝试，而这个谜题的每一块，理想情况下都应该在盒子里预先配置好、预先组装好。”

如果你想稍后更换其中的一些部件，那很好，但在第一天，你会得到一份由一位真正关心每一种食材的厨师设计的完整菜单，你会享受它的。这又是那种许多程序员会觉得，“我知道得更清楚”的事情，而他们在某些非常局部的意义上确实知道得更清楚。每个程序员都知道得更清楚。这就是 Ruby 的基础，即每个程序员在他们的特定情况下都知道得更清楚。也许他们能做一些危险的事情，也许他们认为自己知道得更清楚，然后他们就搬起石头砸了自己的脚，然后他们就真的会知道得更清楚了，因为他们已经砸过一次脚，不会再犯了。但“菜单是 Omakase”就是这个意思。

Lex Fridman

所以你总的来说是看重单体应用 (monolith) 的价值的？

DHH

是的。集成系统 (integrated system)。

Lex Fridman

集成的……

DHH

……有人考虑过整个问题。这也是我自从“微服务”(microservices) 这个词被创造出来就一直反对它的原因之一。微服务本质上源于一个好想法。当你在 Netflix 的规模下，有成千上万的工程师在处理数百万行代码时，你该怎么办？没有人能一次性把整个系统装在脑子里。你必须把它分解。在 Netflix 的规模下，微服务可以是一种合理的方式。当你把这个模式应用到一个 20 个程序员、处理 50 万行代码的团队时，你就是个傻瓜。你根本不需要把方法调用变成网络调用。这是分布式编程的第一法则：不要分布式你的编程。它让所有事情都变得更难。作为程序员，你必须考虑的所有失败情况，在涉及网络电缆时，都会变得无限困难，所以我讨厌过早分解的想法，而微服务正是如此。

单体应用 (monolith) 的理念是，让我们专注于构建一个单一的人类能够真正理解的完整系统，并通过压缩所有概念来将这个范式推向极致，这样更多的东西就能装进一个操作的人类的记忆中，然后我们就可以拥有一个我能真正理解所有 Basecamp、所有 HEY 的系统。这两个系统的代码量都刚过十万行。我见过有人做到这个规模的两倍、三倍，然后就开始出问题了。一旦你超过了五十万行代码，肯定没有哪个人能搞定了，那时你可能就需要某种程度的微服务了。

Lex Fridman

Basecamp 和 HEY 都是十万行代码？

DHH

十万行代码。

Lex Fridman

哇。那很小。

DHH

考虑到 Basecamp 我想大概有 420 个不同的界面和配置，这确实很小。

Lex Fridman

你把前端也算进去了吗？

DHH

不，那是 Ruby 代码。嗯，从某种意义上说它是前端，因为其中一些 Ruby 代码对前端有好处，但它不是 JavaScript，比如说。现在，另一件我们稍后可能会谈到的事是，我们实际上为我们所有的应用写的 JavaScript 都非常少。HEY，一个 Gmail 的竞争对手。Gmail 大概有 28MB 未压缩的 JavaScript。如果压缩一下，我想大概是 6MB，28MB。想想那有多少行代码。

HEY 推出时，我们只用了 40 KB。它试图解决的是同一个问题。你可以用 28 MB 未压缩的 JavaScript 来解决邮件客户端问题，或者用 40 KB，如果你用不同的方式来做。但这本质上是同一个问题。这就是为什么我激烈地反对把前端和后端分开。在我看来，这是对 Web 开发犯下的最大罪行之一，我们至今仍在为其赎罪。我们分离和分割了本应是一个统一的问题解决机制。当你同时负责前端和后端时，你了解整个系统，你就不会陷入那些分化阵营，最终搞出像 GraphQL 这样的东西。

Lex Fridman

好的。让我们快速过一下信条的其余部分。“没有单一范式”(No one paradigm)。

DHH

“没有单一范式”指的是，Ruby 在其核心是一门强烈的面向对象编程语言，但它也是一门函数式编程语言。我告诉你的那个 5.times，你基本上可以做这些匿名函数调用，并且可以把它们链接在一起，非常符合真正的函数式编程语言的工作方式。Ruby 甚至通过让字符串不可变而更接近函数式编程的范畴。来自软件开发所有不同学科和范式的思想都可以融合在一起。例如，Smalltalk 只是面向对象的，就是这样。Ruby 试图主要面向对象，但也借鉴了一些函数式编程、一些命令式编程，能够做到所有这些。Rails 也试图做同样的事情。我们不只是选择一个范式然后贯穿所有东西。

面向对象是其核心，但邀请所有其他学科进来是可以的。受到启发是可以的。重新混合是可以的。我实际上认为 Rails 的主要好处之一就是它是一个混搭。我没有发明所有这些想法。我没有想出 ActiveRecord。我没有想出 MVC 这种划分应用的方式。我把我从各个不同阵营学到和领悟到的所有伟大想法都汇集了起来。不是因为会有一个包罗万象的“万物理论”，而是因为我会有一个融合了各地精华的凝聚体。

Lex Fridman

这个想法是否与单体系统 (monolith) 的美感有些矛盾？

DHH

我认为单体应用 (monolith) 可以被看作是相当宽敞的，像一个大帐篷。单体应用实际上需要借鉴一些函数式编程，来解决那些该学科擅长解决的问题，那个范式擅长解决的问题。如果你也想让面向对象成为核心，我实际上认为，当我看函数式编程语言时，有很多值得喜爱的地方，然后我看到它们在解决问题的某一部分需要改变某些东西时，不得不经历一些疯狂的扭曲，你会想：“天啊，这对于 90% 的问题来说是一个很棒的范式，但当你试图解决最后 10% 的问题时，你完全把自己搞得一团糟。”

Lex Fridman

哦，“推崇优美的代码”(Exalt beautiful code) 是下一个。

DHH

我们已经详细讨论过这个了，这里有一个很好的例子，它很好地总结了 Ruby on Rails 的领域特定语言 (domain-specific language) 特质，即你可以让代码的编写和阅读变得愉快。这对我来说真的很有趣，因为正如我们谈到的，当我开始学习编程时，这甚至都不在考虑范围之内。我甚至不知道那可以是前提的一部分，可以是解决方案的一部分，即写代码可以感觉像写一首诗一样美好。

Lex Fridman

class Project < ApplicationRecord
  belongs_to :account
  has_many :participants, class_name: "Person"

  validates_presence_of :name
end

DHH

看，你能读出来。你甚至没有改变任何东西。

Lex Fridman

就像一首俳句。

DHH

对。是不是很美？

Lex Fridman

是的，很好。真的很好。它有一种直观的特性。好的，我在这里有具体的问题。我的意思是，ActiveRecord，就拿这个岔路来说，那一定是你的最爱功能。

DHH

它是 Rails 的皇冠上的明珠。确实是。它是使用 Ruby on Rails 的决定性特征。而且它的诞生还带有一点争议，因为它实际上使用了一个 Martin Fowler 在《企业应用架构模式》(Patterns of Enterprise Application Architecture) 中描述过的模式。这是任何从事商业系统开发的人必读的最伟大的书籍之一，如果你还没读过，必须马上买一本。《企业应用架构模式》，我想是 2001 年出版的。这是我读过很多遍的为数不多的几本编程书籍之一。它非常了不起。在书中，Martin 描述了一系列关于如何构建商业系统的不同模式。而 ActiveRecord 在其中只是一个不起眼的小注脚。那个模式的名字就叫 ActiveRecord。你可以查一下。它的名字就叫 ActiveRecord。我甚至都懒得自己想个名字。但它允许以一种很多程序员觉得有点反感的方式，将数据库和面向对象结合起来。

他们实际上不想用 SQL 来污染面向对象编程那种美丽的本质。前几天 Uncle Bob 就有一篇咆哮，说 SQL 是有史以来最糟糕的东西。好吧，随便吧，我不在乎。这很实用。我们做的是 CRUD 应用。你从 HTML 表单里拿东西，然后塞进数据库。没那么复杂。你在这两个极端之间放的抽象越多，你越是在自欺欺人。这就是我们做的事。我们在和 SQL 数据库打交道。

顺便说一句，SQL 是那些经受住了 NoSQL 数据库、结构化列表数据长达十年的猛攻，并仍然占据主导地位的东西之一。学习 SQL 是一个很好的投资。每个使用 Web 的程序员都应该对 SQL 有相当程度的了解，即使他们在使用像 ActiveRecord 这样的 ORM（对象关系映射器），你仍然需要理解 SQL。ActiveRecord 所做的，与其说是试图用一种不同的范式来抽象掉 SQL，不如说是让编写 SQL 不那么繁琐，让它更适合在其他领域模型之上构建领域模型，因为你不需要手动编写每一条 SQL 语句。

Lex Fridman

我们得说一下，ActiveRecord 是一个 ORM，它是一个层，让与数据库的通信变得直观和易于人类理解。

DHH

甚至比那更简单。它把表 (tables) 变成类 (classes)，把行 (rows) 变成对象 (objects)。我实际上认为 SQL 大部分都很容易理解。你也可以写一些非常难懂的 SQL golf，但 SQL 的基础，以及很多对 SQL 的批评，都是因为它当初是为人类消费而写的。它实际上相当冗长，特别是如果你在反复做像插入这样的事情。它相当冗长。INSERT INTO table (column1, column2, ...)，然后 VALUES (value1, value2, ...)。

……在你要插入的每一列里，VALUES，括号，每一个与那一列匹配的值，手动写 SQL 会变得很乏味，但它实际上非常易于人类阅读。ActiveRecord 只是去除了那种乏味，它让以一种人类可描述的语言无法做到的方式组合事物成为可能。它把事物组合成方法，你可以组合这些方法，你可以在它们周围构建结构。我不讨厌 SQL，我只是像在编程中做很多事情一样，试图摆脱它们。SQL 并不是其中之一，我只是觉得，“我不想一遍又一遍地写同样的东西。”那是一种，“我们能更简洁一点吗？我们能让它与面向对象稍微匹配得更好一点，而又不试图隐藏我们正在把这些对象持久化到数据库中的事实吗？”

我认为很多 ORM 错就错在这里。它们试图生活在纯粹的对象世界里，从不考虑那些对象必须被持久化到一个 SQL 数据库中，然后它们就想出了一些复杂的来回转换的方式。ActiveRecord 说：“你知道吗？接受现实吧。”这个记录，这个对象，不会被保存到某个 NoSQL 数据库里，它会被保存到一个 SQL 数据库里，所以就把整个东西都围绕着这个来构建。它会有属性，那些属性会对应数据库里的列。没那么复杂，别把它搞得那么复杂。

Lex Fridman

是的，但我要说，我个人很喜欢 SQL，因为我是个算法爱好者，所以我喜欢优化，我喜欢知道数据库的实际工作原理，这样我就可以匹配 SQL 查询和表的设计，从而从表中挤出最佳性能。好的。基于那张表的实际使用方式。我认为这正说明了理解 SQL 的价值。我想知道，因为我开始看 ActiveRecord，它看起来真的很棒。那会让你变懒吗？不是你，而是一个刚开始使用 Rails 的人，你可能可以不真正学习 SQL 就混过去，对吧？

DHH

只要你想停留在能力的入门级别就行。这实际上是我对 Rails 的 overarching 使命，就是把入门门槛降到足够低，让某人可以在基本上什么都不懂的情况下开始在浏览器上看到东西。他们可以运行 rails new blog，运行几个生成器，他们就有了一个完整的系统……他们什么都不懂，但这是一个学习更多的邀请。让我感到兴奋的，这也和 AI 的讨论有关，是当这被变成一种 meme，即程序员不再需要有能力。“AI 会搞定，生成器会搞定。我不需要懂 SQL，ActiveRecord 会帮我抽象掉。”不不不。朋友，停一下。这里的道路是通往能力的。我是在教你东西。

我理解我不可能在五分钟内教你所有东西。任何在有价值的事情上做得好的人，都不可能在五分钟内学会所有东西。如果你想成为一个全面发展的应用开发者，那需要数年时间，但你实际上可以在几天内变得有些生产力，你可以在几天内找到乐趣。当然，你会在几分钟、几小时内找到乐趣，然后随着时间的推移，我可以教你更多。ActiveRecord 就像是说：“是的，是的。好的，从这里开始，然后，下周，我们上一堂 SQL 课。”

Lex Fridman

实际上，你有一个我很喜欢的优美表达。那就是一个伟大的编程语言，比如 Ruby，有一个平缓的坡道，但这个坡道可以通向无限。

DHH

完全正确。

Lex Fridman

是啊。它非常容易上手，非常容易开始……

DHH

而且它永无止境。

Lex Fridman

是啊。

DHH

总有更多的东西要学。这也是我仍然觉得编程很有趣的原因之一，我仍然在学习新东西，我仍然可以融入新东西。Web 作为一个领域足够深，你永远也学不完。

Lex Fridman

“提供锋利的刀”(Provide sharp knives)。

DHH

这是个很好的原则，因为换一种说法……相反的说法，Java 的说法是，“不要提供会伤到脚的枪”(Do not provide foot guns)，对吧？

Lex Fridman

是啊。

DHH

我不想给你一把锋利的刀。你是个孩子，你驾驭不了一把锋利的刀。这是一把钝的黄油刀，去切你的牛排吧，对吧？那是一种非常令人沮丧的体验。你想要一把锋利的刀，即使你可能会割伤自己。我信任人类，就像数学信任人类一样。也许你会切掉一根手指。好吧，你不会再那么做了。谢天谢地，如果那是一根虚拟手指，它会长回来的。你的能力会增长，用锋利的工具工作更有趣。

Lex Fridman

这实际上有助于那条通向无限的坡道。

DHH

是的，有助于学习。

Lex Fridman

“重视集成系统”(Value-integrated systems)。

DHH

我们已经谈到那个了。Rails 试图解决整个 Web 问题，而不仅仅是一个小组件。它不是留给你一堆需要自己拼凑的零件。

Lex Fridman

“进步优于稳定”(Progress over stability)。

DHH

你知道吗？如果有一条原则过时了，可能就是这一条了。在现阶段，Rails 已经在很多代版本中都非常稳定。最新的主要版本 Rails 8，对于任何运行 Rails 7 的人来说，基本上是一次无操作的升级。Rails 7 对于任何运行 Rails 6 的人来说，也几乎是一次无操作的升级。我曾经认为，为了获得进步、为了保持在新事物的前沿，需要更多的变动，我写这个的时候还没有经历过 2010 年代 JavaScript 社区的屈辱，在那里，稳定似乎不仅不受重视，实际上还被鄙视。变动本身就是我们应该追求的价值。如果你三个月后还在用同一个框架，那你就是个傻瓜，我看到那个后实际上退缩了。如果我今天要写信条，我会写得不一样。我不会说，“进步优于稳定。”

Lex Fridman

也许这也与编程语言的年龄有关。

DHH

也许吧，或者说对问题有了更深的理解。我认为技术领域一个非常迷人的地方在于，我们有一种感觉，就是一切都在不断地快速变化。不，不是的。一切都以冰川般的速度在变化。偶尔会有一个范式转变，就像现在 AI 发生的事情一样，就像 2007 年 iPhone 推出时发生的事情一样，就像 95 年互联网出现时发生的事情一样。这基本上是我职业生涯的总和，三件事改变了。其他一切都只是增量式的小改进。你能认出 2003 年写的 Rails 应用。我知道，因为我当时写的那个 Basecamp 至今仍在运行，每年创造数百万美元的 ARR，为客户提供服务，使用的是当时推出的初始版本，而且它看起来，如果我眯着眼看，和我今天写的 Rails 代码很像。大多数事情都没有变，即使在计算领域，这其实是一件好事。我们在 JavaScript 生态系统中看到了，当所有人都对不断的变动感到疯狂时会发生什么。事情并没有那么频繁地改变。

Lex Fridman

顺便说一句，在这个小岔路上，你刚才明显地、口头上改变了你 15 年前的想法？

DHH

是的。

为什么管理者毫无用处

Lex Fridman

这很有趣。你有没有注意到这些年来你改变了很多想法？

DHH

我会说：“哦，是的。”然后也会说：“哦，不。”意思是，有些关于人性、机构、编程、商业的根本性问题，我确实改变了想法。然后我也经历过一些甚至更有趣的事情，就是我以为我改变了想法，尝试了一种新的方式，结果意识到我最初为什么会有那个观点，然后又回去了。这两种情况都有。后一种情况的一个例子，比如 37 Signals 的管理者。很长一段时间里，我会抨击工程经理，认为他们对于一个小甚至中等规模的公司来说是不必要的负担。有一次，我甚至开始有点怀疑自己了。我开始想：“你知道吗？也许所有程序员真的都需要每周和他们的工程经理进行一次一对一的心理治疗，才能成为一个完整的个体。”

我们试了几年，雇了一些非常好的工程经理，他们按照你应该做的方式来做工程管理，就像到处都在做的那样。在那之后，我想：“不。不，我当初是对的。这才是正确的，我们不应该有经理。”不是每个程序员都需要每周和工程经理进行一次心理治疗，我们不需要这些没完没了的预定碰头会，我们不需要所有这些会议。我们只需要让人们安安静静地，在长时间不被打扰的时间里，去解决他们喜欢的问题。幸福感就在这里找到，生产力也在这里找到，如果你能做到这一点，你绝对应该这么做。当这种情况被打破时，工程管理就成了一种必要的恶。

Lex Fridman

那么，支持管理者的理由是什么呢？

DHH

支持管理者的理由是，如果你确实有很多员工，就会有很多工作自然而然地出现。一对一是其中一个例子，程序员需要有人定期沟通。还有一个理想化的版本是，需要有人来指导初级员工的职业发展，给他们提供修正性的反馈，以及所有这些其他的事情。并不是说，在抽象层面上我不认同其中一些事情，但在实践中，我发现它们常常创造的问题比解决的要多。一个很好的例子是，你能从一个在你的工作上不如你的人那里得到反馈吗？你能得到一些反馈，你能得到关于你在工作中的表现的反馈。你对他人是否礼貌？你是不是一个好的沟通者？好的，是的，但你无法得到关于你工作的反馈，而那更重要。

更重要的是，如果你希望在职业上进步，你应该在比你更擅长你的工作的人手下和身边工作，而我合作过的每一个程序员，都远比对学习中层管理者能教他们的那些小技巧更感兴趣于在那个指标上提升自己的职业生涯，即提升自己的技艺。这并不是说那些没有价值，也不是说成为一个更好的人或更好的沟通者没有价值。当然，所有这些都有价值，但如果我必须二选一，我更看重能力。再说一次，我强调这一点无数次，因为我知道人们有时会听到什么，他们会听到“天才混蛋”也没关系，那很好，你应该原谅各种恶意行为，只要某人真的擅长他们做的事。

我完全不是那个意思。我想说的是，能力的历史就是向比你更优秀的人学习的历史，而这种关系应该优先于其他一切。当引入工程经理时，这种关系在某种程度上就被搁置了。现在，有趣的是，这个对话又回到了我们之前谈论的话题。大多数工程经理实际上以前都是程序员。他们至少在某种程度上懂编程，但我一次又一次地看到，他们很快就会失去对编程的感觉和手感，很快就变成那种只会检查进度的尖头老板。“只是看看我们在项目 A 上的进展，如果你需要什么的话，”或者，“我们真的要交付了吗？”好的，是的。也，不。闭嘴，让我一个人待着。让我编程，然后我再上来透口气。

我会和其他程序员交流，我们可以切磋，可以学到东西，我可以和他们一起琢磨问题，然后我们就能前进。如果你回顾一下计算机行业的历史，所有伟大的创新，都是由没有工程经理的小团队完成的。都是由技术高超的个体组成的。你请过 John Carmack 来这里。我曾经非常敬佩他的软件，不仅因为我喜欢《雷神之锤》(Quake)，不仅因为我喜欢他们做的事情，还因为他分享了一些关于公司如何运作的信息。那里没有经理，或者也许他们有一个商务人员做一些商务上的事情，但那只是为了拿到钱。其他一切基本上都只有设计师和程序员，他们大概有八个人，就创造了该死的《雷神之锤 2》。你为什么又需要所有这些人呢？

你为什么又需要所有这些经理呢？我想，再强调一次，在一定的规模下，这种模式确实会失效。让十万个程序员在没有任何产品妈妈或爸爸告诉他们该做什么的情况下自由奔放是很难的。我理解这一点。然后即使我这么说，我也不完全理解，因为如果你看看像 Gmail 这样的东西，那就像是 Buchheit 当时在谷歌做的一个副业项目。即使是所有这些大公司，它们很多经久不衰的长期价值，都是由那些没有该死的经理的人创造的，而这并非偶然。这是一种直接的因果关系。多年来，我在某种程度上对管理这个概念变得更加激进，至少对我自己而言，知道我是谁以及我想如何工作，因为另一部分是我不想成为一个经理，也许这只是我作为一个内向的人，不喜欢每周都和人进行一对一通话的投射，但它也概括了我如何能够在我的职业生涯中取得进步。

我直到有了一扇可以关上的门，并且六个小时内没人能打扰我，才真正地在 Ruby 或其他方面达到了一个新的水平。

Lex Fridman

在公司里，一个可能的原因是招聘经理非常容易，而且经理也能从你这里分担责任，所以如果你只有一群程序员在到处跑，你的责任……处理每个问题的基本原则是需要脑力劳动的。

DHH

是的。

Lex Fridman

经理就像是，“你可以放松了，一切都会被照顾好的。”但他们接着又会雇佣自己的经理，然后就这样成倍地增加。我很希望我们美国的一些大公司能有一个额外的分支，我们可以一直运行……也许物理学家可以想出如何分割这个模拟，让那个分支里所有的经理都被移除。就在那个分支里，公关和传播人员也移除，甚至律师也移除。只留下工程师，让我们看看会发生什么，然后再把它合并回来。

DHH

我有种感觉，你已经在 37 signals 运行那个分支 20 年了。我尝试过分叉到另一边，我尝试过全职聘请律师，我尝试过聘请工程经理，我可以告诉你，在 50、60 人的规模下，当那些个体或者那些角色都不存在时，生活要好得多……这从来不是关于个体，而是关于角色。当那些角色不在你的组织里全职存在时。偶尔，你需要一个经理。偶尔，你需要一个律师。我可以偶尔扮演经理的角色，没问题，然后我可以再把它降为零。这几乎就像一个云服务。我想要一个经理服务，我可以在这周调用它七个小时，然后在接下来的三个月里把它降为零。

Lex Fridman

是啊，我读到过，不知道现在还是不是这样，Basecamp 是一个 LLC，而且没有 CFO，就是没有全职的会计。是这样吗？

DHH

现在我们确实有了一位财务主管。但在公司成立的前 19 年里，我想是没有的。我们基本上只靠一个会计来做账，就像你开一家小冰淇淋店一样，只不过随着时间的推移，我们的收入达到了数亿美元。这个规模显得有点古怪，而且有时候你也会爱上自己的古怪，以至于达到一种不健康的程度，我肯定也曾这样做过，我们应该早一点更勤奋地算账。这部分也是因为我们一直利润丰厚，销售的软件基本上可以有无限的利润率，这让你可以在很多事情上侥幸过关，而你或许本不应该这样做。部分让我吸取这个教训的是，当我们意识到我们没有在我们有业务关联的美国不同州份收取销售税时，我们花了大约两年时间和 500 万美元的和解金和清理费才摆脱那个烂摊子。在那之后，我想：“好吧，好吧，我们可以雇一个财务人员了。”

Lex Fridman

好的。

DHH

我们现在有一个很棒的财务人员，Ron，他实际上最终替代了我们以前有的另一个职位。我们以前有一个全职的数据分析人员，他会做各种各样的洞察挖掘，比如“人们为什么会注册这个东西？”我们这样做了 10 年，然后意识到，“你知道吗？如果我可以在数据分析人员和会计之间选择一个，我选会计。”

小团队

Lex Fridman

我非常喜欢这个，从很多层面上。我们能不能稍微深入一下你给的那个建议，即小团队更好？我认为那真的更少……少即是多。你之前怎么说的？“差即是好”？哦，抱歉。

DHH

“差即是好”(Worse is better) 在技术采纳上很多时候是这样。

Lex Fridman

是啊。

DHH

我认为这实际上源于同一件事。它源于这样一个事实：许多伟大的突破都是由，甚至不只是小团队，而是由个人创造的，由个人写出来的东西。一个人写的某些东西，在某些参数上，他们做的东西更差。当然，当一个人必须做出一个大公司有成百上千开发者可以投入去解决的问题时，他们的东西会更差，但在许多其他参数上，那种“差”就是价值，那种“少”就是价值。在《Getting Real》这本书中，我们早在 2006 年就写过，我们谈到了“更少的软件”这个概念。当我们在 2004 年刚开始做 Basecamp 时，人们总是问我们：“你们不害怕微软吗？他们有更多的资源，更多的程序员。如果他们看上了你们这个小众领域，然后派一千个程序员来解决这个问题怎么办？”

我的回答，部分原因可能是我当时才 24 岁，首先是：“不，一点也不担心。”但真正的答案是，他们不会做出同样的东西。你不可能用一个一千人的团队做出 Basecamp 这样的软件。你会做出的是一千人团队会做出的软件，而那根本不是一回事。无论是最终用户系统，还是开源系统和基础系统，很多主要的突破都是由个人或非常小的团队完成的。即使是所有那些关于苹果的经典历史，也总是说，嗯，有一个大的组织，但真正做出突破的团队，是四个人，是八个人，从来不是 200 人。

Lex Fridman

大团队似乎会拖慢事情的进度。

DHH

是的。

Lex Fridman

这太有趣了，部分原因是经理的问题。

DHH

因为人类无法扩展，人类之间的沟通当然也无法扩展。你基本上会得到网络成本效应。每当你增加一个新节点，成本就会呈指数级上升。这也许是我如此喜欢在 Basecamp 没有经理的关键原因，因为我们默认的团队规模是两个人。一个程序员，一个设计师，一个功能。当你在那种规模下运作时，你不需要复杂性，你不需要先进的方法论，你不需要多层管理，因为你可以直接去做。小团队的魔力在于他们就是去做。他们不需要争论，因为我们不需要设定方向，我们不需要担心路线图。我们可以坐下来做点东西，然后看看它好不好。当你可以只管做东西的时候，你就不需要计划，如果你可以摆脱计划，你就可以追随从代码、从产品、从你正在做的东西中浮现出的真相。

当你落后一步时，你更清楚下一步该怎么走，而不是提前 18 个月去规划所有的步骤。“我们如何从这里走到很远的地方？”你知道吗？这很难提前想象，因为人类在这方面很差。也许有一天 AI 会比我们好得多，但人类可以一步一个脚印地走。那不难，那能让你摆脱所有那些复杂性。过程变得简单得多，你需要的人少得多，这会产生连锁反应，你需要的流程少得多，你需要在会议上浪费的时间也少得多。你可以花那些漫长而美好的日子和星期，不受打扰地解决你关心且有价值的真正问题，然后你会发现那正是市场真正想要的。

大多数时候，没有人会因为某物背后有一个大公司而购买它。他们购买某物是因为它好，而你得到好东西的方式不是坐下来开会讨论，而是去尝试，去创造。

Lex Fridman

一个人，说实话，一个人在 100 个小时的深度工作、专注工作中能做的事情，真是不可思议。甚至更少。

DHH

我告诉你，我精确地记录了我在 Basecamp 第一个版本上花费的小时数。我之所以这样做，是因为当时我是以合同工的身份为 Jason 工作的。他付我……我刚要说每小时 15 美元，那是我刚开始工作时的报酬。我想他把我的工资提高到了光荣的 25 美元，但我当时是按小时计费的，我知道 Basecamp 第一个版本的发票是 400 个小时。这就是 2004 年一个独立的个体，创造一个完整的系统所花费的时间，这个系统后来创造了数亿美元的收入，并且至今仍然表现出色。一个人，只有我一个人设置所有东西。这个故事的一部分是 Ruby，一部分是 Rails，但很大一部分也是我加上 Jason 加上 Ryan 加上 Matt。

那是当时整个公司的人员，我们能用这么小的团队创造出具有持久价值的东西，正是因为我们是一个小团队，而不是尽管我们是一个小团队。“小”不是一个垫脚石。这是人们脑海中的另一个误区，也是我们《Rework》这本书的一个重要主题，它给了创业者们拥抱小团队的许可，不是把它当作一个中转站，不是“我正在努力变成一个千人公司”。不，我其实喜欢作为一个小团队。小团队更有趣。如果你问几乎任何人，我相信 Toby 也会这么说，即使在他那样的规模下，创造东西的纯粹乐趣也在于和一小群人一起创造的乐趣。现在，当你有一个大公司时，你可以在不同的规模上产生影响，我完全承认这一点，我也看到了它的吸引力，但在实际创造东西的过程中，永远都是小团队。永远。

杰夫·贝索斯 (Jeff Bezos)

Lex Fridman

你如何保护小团队？Basecamp 成功地保持了小规模。你必须击退的恶龙是什么？基本上，你赚了很多钱，就会有增长的诱惑，那么你如何不增长呢？

DHH

不要拿风险投资。

Lex Fridman

好的，那是第一步。

DHH

那是第一点。

Lex Fridman

首先……

DHH

第二点是……

Lex Fridman

……每个人都拿风险投资，所以你已经走了。

DHH

这在很长一段时间里都是答案，因为问题不仅仅是风险投资，而是别人的钱。一旦你拿了别人的钱，完全可以理解，他们想要回报，而且他们更希望获得尽可能大的回报，因为不是他们坐在那里写代码，不是他们从创造东西中获得日常的满足感，从编辑器里凿出优美的代码诗篇，对吧？他们没有那种满足感。他们可能会从看到一个好东西被创造出来中获得满足感，这很公平，但他们肯定也会从更高的回报中获得满足感。有一种感觉，尤其是在风险投资领域，明确表示，你拿钱的全部目的就是为了达到 10 亿美元或更多。

现在，通往那条路的路径通常是遵循既定的 playbook，而当涉及到软件时，企业销售 playbook 就是那个 playbook。如果你做 B2B 软件 SaaS，你会尝试找到产品市场契合点，一旦你找到了，你就会放弃你的中小型客户，用庞大的销售团队去追逐那些大客户，到那时，你就有了 1000 人，生活也就变得糟糕了。

Lex Fridman

话虽如此，人们只是对此感到好奇。你有机会认识了杰夫·贝索斯。他投资了 Basecamp，但不是控股……

DHH

他买的是二级市场的股份。有趣的是，当……投资有两个含义。通常人们想到投资，会认为是投入增长资本，因为你希望企业雇佣更多的人，做更多的研发，以便能发展得更大。贝索斯实际上没有那么做。他直接从我和 Jason 手中购买了所有权股份，那次购买的全部收益都进入了我和 Jason 的个人银行账户。是个人银行账户。没有一分钱进入公司的账户，因为我们不需要钱来增长。我们所需要的，或者说我们当然很享受的，在某种程度上也许是那份信任票，但更多的是，把一些东西变现所带来的安全感，让我们敢于拒绝风险投资的大笔资金。

这基本上是一种疫苗，防止我们想从那些想把公司带到一个我们不想去的地方的人那里拿更大的支票。Jeff 给了 Jason 和我足够的钱，让我们能安心地拒绝所有这些人，而不会在六个月后公司倒闭时，我们还在自责，说：“我们曾经有过价值数百万的东西，现在什么都没有了，还得担心房租和生活费。”

Lex Fridman

这是一张信任票。我很想听听 Jeff 对这个故事的看法，因为他并不需要钱。我想，这可能只是相信人，希望世界上能有酷炫的东西被创造出来，并从中赚钱，但不是那种……

DHH

百分之百，Jeff 的动机不是为了回报，因为他实际上有一个团队，他的私人办公室，负责管理这些投资，他们对我们给他的投资方案做了计算，那个方案荒谬到 Jason 和我写下我们的指标时都笑得前仰后合。我说：“没人会付这个价的。没人会给我们这么高的收入倍数，这没关系。”我的意思是，我们接那个电话基本上是出于对 Jeff Bezos 甚至想看我们一眼的敬畏。“你知道吗？我们不想要风险投资，我们不需要别人的钱，但我们就给他一个任何理智的人都不会同意的 bullshit 数字，然后我们就可以各走各的路了。”

他的投资团队说：“Jeff，不行。这根本不符合经济逻辑，他们的收入那么少，要价却那么高。”Jeff 只是说：“我不在乎，我想投资这个人。”因为对他来说，在当时，那只是小钱。Jason 和我每人拿了几百万美元，那天日元和美元之间的汇率波动，可能对他的净资产的影响比我们的投资大十倍。Jeff 似乎真心有兴趣和有趣的人、有趣的公司在一起，帮助别人走得更远。我实际上带着某种程度的遗憾回顾那段关系，因为我把那份信任票理所当然地接受了，以至于我有点惭愧。这些年来，我对亚马逊做的一些事情批评得更多了，我现在觉得这是合理的。

那只是处理这件事的一部分，但在经济意义上，他给了我们那种信心。他给了我们经济上的信心，但他也给了我们一位首席执行官的信心，他当时可能管理着美国最重要的互联网业务，他会参加我们每年一次的电话会议，然后基本上就是说：“是的，你们在做很棒的事情。你们应该继续做很棒的事情。我读了你们的书，很棒。你们推出的这个东西，很棒。你们就应该多做这些。我其实不知道怎么运营你们的业务，你们自己知道。”

Lex Fridman

书已经出版了。从一个粉丝的角度，我很好奇 Jeff Bezos 是如何能够看到……因为对我来说，你和 Jason 在科技领域是特别的人，而 Jeff 能够看到这一点，对吧？看到这一点有多难？

DHH

他确实很早就看到了，我认为这是 Jeff 比几乎任何人都做得更好的地方。他在其他人甚至还没睁开眼之前就发现了那个机会，或者说，他肯定比任何人都更早、更坚决地愿意下注，而且他一次又一次地被证明是正确的。我们不是他做的唯一一笔投资，而且当然，亚马逊有一个非常长期的愿景，远比我曾经有勇气保持的要长……我把自己看作一个长期思考者，但和 Jeff 玩的游戏相比，我玩的只是小孩子的游戏。当我回顾亚马逊在互联网泡沫破灭前后的经济状况时，它们看起来很荒谬。他们亏损了那么多钱，被市场那么讨厌。没有人相信它会变成现在的样子，但 Jeff 相信，那种程度的信念，我真的渴望拥有。

我想那是我从那段关系中学到的主要东西之一，就是你可以 просто相信自己。在那种逆境下，达到那种程度？那太荒谬了。他在我们这个级别上做了那么多次，如果我还在怀疑自己，那就太可悲了。

Lex Fridman

是啊。我认为亚马逊是那种公司。这些年来它受到了很多批评。这是人类我不太欣赏的一点，我们很快就把一件事带来的好处视为理所当然，然后就开始批评那件事。就像飞机上的 Wi-Fi。

DHH

正是如此。

Lex Fridman

我认为亚马逊，可以说亚马逊是过去 100 年来最伟大的公司之一。

DHH

当然，我认为这个论点很容易成立。我还认为，成为过去 100 年来最伟大的公司之一所付出的代价，就是大量的诋毁者、大量的反对和大量的批评。这实际上是宇宙恢复了秩序。我在互联网上这么久以来，最喜欢的老师之一是 Kathy Sierra。我不知道你是否知道她的作品，但在残酷的互联网把她赶走之前，她只活跃了短短几年，但她写了一个名为《创造热情的用户》(Creating Passionate Users) 的博客，她在我的脑海里刻下了这个关于宇宙平衡的概念。如果你在创造一个很多人都喜欢的有价值的东西，你必须创造一股与之相等且相反的仇恨力量。你不可能在拥有喜欢你所做之事的人的同时，却没有讨厌你所做之事的人。

唯一的出路就是平庸。如果你无聊到、无趣到没有人关心你是否存在，是的，你不会有仇恨者，但你也不会有那些真正享受你工作的人所带来的影响。我认为亚马逊就是这种现象的大规模体现，对吧？他们给技术、给商业带来了如此多的价值和改变，以至于他们必须拥有一个黑洞大小的仇恨者群体。否则，宇宙就会直接倾覆。

Lex Fridman

让我问问你关于小团队的事情。你多次提到 Jason，Jason Fried。你们合作了很长很长时间。也许可以说他更多地是负责设计和商业方面，而你是技术、工程方面的奇才。这么多年来，你们创造了这么多令人惊叹的产品，是怎么做到没有互相残杀的？这是一个很棒的合作故事。你能谈谈合作吗？你能说说你喜欢 Jason 的什么，从他身上学到了什么？为什么这能行得通？

DHH

首先，我要说的是，这些年来我们确实有好几次想杀了对方，但我想在过去十年里少了很多。在早期，我们的产品讨论非常激烈，以至于当我们在办公室里讨论，周围还有其他员工时，他们中的一些人真的会担心公司要散架了，因为房间里传出的音量会非常大，听起来非常尖刻，他们真的会担心整个公司会分崩离析。有趣的是，在当时，我们从来没有那样的感觉。我们总是觉得那只是在激烈地寻找更好的东西，我们之所以能够忍受在想法上的那种程度的对立，是因为那是关于想法的。那不是关于个人的，也从来没有真正变得个人化。不是从来没有，是真的没有变得个人化。不是像，“Jason，你这个混蛋。”而是像，“Jason，你这个傻瓜，你这个傻瓜是因为你看待这个问题的方式错了，让我告诉你正确的方式。”

Lex Fridman

作为一个小岔路，我想说，有些人说过，我们可能会回到这个话题，说你有时候在网上会发脾气等等。我从来不这么看，因为那是一样的东西。也许我没有看到你发脾气的真正痕迹，但通常都是关于想法的，只是一个兴奋、充满激情的人。

DHH

我正是这么想的。它并不总是以那种方式呈现出来，我能理解为什么旁观者有时会看到一些看起来像是我在攻击人而不是在讨论问题的事情。我确实认为我一直在努力改进这一点，但在我和……的关系中……

DHH

我确实认为我一直在努力改进这一点，但在我和 Jason 的关系中，我认为之所以能如此顺利，是因为我们各自有独特的专长领域，我们在这些领域完全信任对方。Jason 信任我做出正确的技术决策。我信任他做出正确的设计和产品方向决策，然后我们可以在商业、市场营销、写作和其他方面进行重叠和分享。所以这是一件事，如果你和一个与你做完全相同事情的人一起创业，并且你们不断地争论谁更有能力，我认为那会困难得多，也更不稳定。所以如果你创业，你们俩都是程序员，而且你们都做同一种编程，祝你好运。我认为那很难。

我试着选择一条更容易的路，和一位设计师合作，我知道至少有一半的时间我可以直接委托给他的经验和能力，然后说：“你知道吗？我可能有意见。我随时都有关于设计的意见，但我不需要赢得争论，因为我信任你。”现在，偶尔我们会在商业或方向上有重叠，我们都觉得自己在其中有很强的利害关系，我们都声称自己在那方面有能力，但出于某种原因，我们也都有一种长远的眼光，我会说：“你知道吗？我认为我们在这里错了，但正如我从 Jeff Bezos 那里学到的，顺便说一句，我会‘不同意但承诺执行’。”那是他早期教给我们的一个绝对关键的教训，甚至可能对确保 Jason 和我能合作四分之一个世纪起到了决定性作用。“不同意但承诺执行”(Disagree and commit) 是 Jeff Bezos 的经典名言之一。

Lex Fridman

我只是很惊讶，小野洋子 (Yoko Ono) 还没有出现。你知道我的意思吗？这个世界上有太多的小野洋子了。

DHH

如果没有部分原因是我们不是整天黏在一起，这可能已经发生了。我们职业生涯的大部分时间，我们甚至都不在同一个城市。我搬到美国后，在芝加哥住了几年，那时我们刚起步，但在 2005 年之后，我搬到了马里布，然后住在西班牙，然后又住在哥本哈根。Jason 和我，从我们关系的建立之初，就学会了一种非常高效的合作方式，我们实际上不需要太多交谈。在任何一个星期里，如果 Jason 和我直接交流沟通的时间超过两个小时，我都会感到惊讶。

Lex Fridman

是啊。有时候，就是那些基本的人类摩擦，会随着时间的推移不断累积。

DHH

是的。我想，如果你和另一个人靠得太近，那个人最好是你的配偶，如果时间太长、太频繁的话。

Lex Fridman

是啊。但即使是那样，新冠疫情也真的考验了这种关系。看着很有趣。

DHH

是的，我认为保持一些距离是……这有点反直觉，因为我想很多人认为合作越多越好。点子越多碰撞越好。但 Jason 和我，出于某种原因，在职业生涯早期就得出了一个结论：绝对不是。那完全是胡扯。这就是为什么我们是远程工作的坚定支持者。这就是为什么我喜欢在我的家庭办公室工作，我可以关上门，六个小时不见到另一个人。我不想一直和你碰撞想法。我想偶尔和你碰撞想法，然后我想自己去实现那些想法。

有太多的“碰撞”，却没有足够的“得分”，不够的“灌篮”，我认为这是高管角色的一大陷阱。一旦一个创始人把自己提升到高管的位置，他所做的只是告诉别人该做什么，那就是他们 24/7 生活的领域。他们只生活在想法的领域。“哦，我可以告诉更多的人，做更多的事情，我们就可以看着它发生。”如果你真的必须参与到执行中去，你就会放慢你的马。你知道吗？我上周有个好主意。我要把剩下的好主意留到下个月。

为什么会议是有害的

Lex Fridman

经理和高管层有一种做事的冲动，而那种“做事”通常意味着开会。所以这就是为什么你说……

DHH

是的。他们的工作就是告诉别人该做什么。

Lex Fridman

是的。还有会议，所以这是你强烈反对的事情之一就是会议……

DHH

会议是有害的。我认为这与 Jason 和我的关系紧密相关。如果我必须计算一下我们 24 年合作中开过的会议总数，就是我们亲自面对面坐下来讨论一个话题的次数，可能比一家大型科技公司三个月的会议还要少。我们真的没有做过那么多。我们没有把它消耗殆尽。特朗普有一次提出了一个有趣的比喻，说一个人一生中能走的步数是有限的。这是长寿的论点。你能做的活动就那么多，然后你就用完了。

这个想法的核心可以应用到人际关系上。我们之间能有的交流是有限的。我们能在一起的时间也是有限的，你会把它消耗殆尽。Jason 和我都很小心，不去消耗彼此。我认为这对于我们关系的持久性绝对是关键，再加上那种信任，以及我们真的喜欢工作本身这个事实。我们不只是喜欢头脑风暴，那种我们只是想出好点子的地方。不，我们喜欢去实现那些点子，我们喜欢亲自成为那个过程的一部分。我喜欢编程，他喜欢做设计。我们可以各自去做自己的小事情，很长时间。偶尔我们会聚在一起说：“嘿，我们来发布一个很棒的产品吧。”

Lex Fridman

这可能听起来像是我在让你做心理治疗，但我发现我自己有时会想要或渴望开会，因为我感到孤独。远程工作就是一个人坐着，我不知道，长时间下来会变得非常孤独。

DHH

我给你个建议。找个妻子。

Lex Fridman

是的。该死的。

DHH

生几个孩子。

Lex Fridman

好吧。

DHH

家庭真的是孤独的良药，我尽可能真诚地这么说。我职业生涯早期远程工作时，确实有过你描述的那种感觉，当时我就是一个人住在一套公寓里，一个典型的刻板印象，我刚搬到芝加哥时，地板上只有一个床垫。然后我买了一台大电视，甚至都没挂起来，然后我有一堆 DVD。我基本上就是，工作很长时间，然后回家就那样，那并不好。真的不好。我确实认为人需要人。如果你在工作中得不到，而我实际上有点不希望在工作中得到，至少我不希望每周 40 个小时都那样。那不是我喜欢的。

你需要别的东西。你生活中需要其他的关系，如果你能找到一个你真心想花很多时间在一起的人，那就没有比这更深厚的关系了。这很关键，我认为对 Jason 和我来说都很关键，我们都有家庭很长时间了，这让你以一种方式脚踏实地，创业公司的冲刺可以换成持久公司的马拉松，你会以一种方式安定下来。我们刚才简短地谈到，我有时会激动起来。我的意思是，很多时候，也许是大多数时候，我对某些话题会激动起来，但现在我激动的方式和 24 岁时不一样了。我仍然对想法充满激情，努力寻找正确的东西，但拥有一个家庭，遇到我的妻子，围绕着它建立一个生活，以一种完全陈词滥调的方式让一切都变得平和了，但我认为这实际上是关键。

我认为，如果我们能让更多的年轻人，甚至更年轻的人，不要等到三十多岁甚至四十出头才和某人结婚，我们会过得更好，我们的商业关系也会更稳定，因为人们会在别处得到那种滋养的人际关系。现在，当我说这些的时候，我也承认，这些年来有很多伟大的企业不是远程建立的，而是由一群流氓在办公室里长时间工作建立起来的。

我的意思是，John Carmack 和 Tim Sweeney 都在 90 年代的职业生涯中谈到过，那基本上就是工作、睡觉、和办公室的伙计们混在一起，对吧？完全公平。那从来没有吸引过我。Jason 和我对于每周工作 40 小时就足够了这一点看法一致，如果我们想走得更远，不仅仅是为了建立一个风投案例然后退出的那五到七年，而是可能 10 年、20 年甚至更久，我们就需要成为完整的人，因为只有那种完整的人性才能走得更远，这包括在工作之外建立友谊，有爱好，找到伴侣并拥有家庭。而整个这种存在，即工作不是生活中唯一的事情这个支撑，与我们已经存在了 25 年这个事实完全相关。有太多的，尤其是在美国，是错误的权衡。哦，你想建立一个成功的企业？那么你可以在金钱、享受、家庭或健康中选一个。

什么？我们为什么必须放弃所有这些？现在，再说一次，我不是说，在某些时刻，某些人生阶段，你可以冲刺，但我想说的是，如果那个冲刺变成了十年，你会为此付出代价的。而且你会以我一次又一次看到的方式付出代价，那看起来是一个非常糟糕的交易，即使它成功了。顺便说一句，大多数时候它并不成功。大多数时候创业公司都会倒闭。大多数时候人们花五、七年时间做一些没有结果的事情，他们也得不到回报。然后他们就坐着后悔，说：“我 20 多岁的时候到底发生了什么？”很早以前，Jason 和我基本上就达成了协议，我们一起工作不会导致那种后悔，我们会允许自己和对方在工作之外建立一个完整的生活。而这行得通这个事实，我觉得几乎像是禁忌知识。

当然，在美国的技术圈里，这是我们 20 年来一直试图倡导的事情，但我们仍然因此受到抨셔。就在两天前，我又和某人在推特上吵了一架，他说：“哦，好吧，也许那行得通，但你们没有变成 Atlassian，所以你们是失败的。Basecamp 不是 Jira，所以你们还费什么劲呢？”这是一种非常有趣的赢家通吃的心态，除非你在所有方面都主宰了其他所有人，否则你就输了。而生活中的很多事情远比这更开放，允许多个赢家，我们可以最终拥有一个多年来赚取了数亿美元的企业，我们保留了其中的大部分，可以做任何我们想做的事情，这就足够了。这很好。这很棒。这实际上是值得追求的东西。当然，这应该是某人可以考虑选择的道路，而不是那种主导一切的风险投资独角兽或破产的心态。