信号与噪音：DHH 影响我的二十年
原创 张汉东 2026-09-04 04:14 美国
我这一生，可能都在寻找信号📶
最近，我开始深度使用 Omarchy。
有一天坐在电脑前，我突然产生了一种很熟悉的感觉。
这种感觉，我上一次如此强烈地体会到，已经是二十年前了。
2005 年，我刚刚大学毕业。
那一年，我在网上看到 DHH 用十五分钟，通过 Ruby on Rails 做出了一个 Blog。
今天再回头看，那当然只是一个再普通不过的 Web 应用。
数据库、Model、Controller、View，几条命令，一些约定，一个 Blog 很快就跑了起来。
但对当年的我来说，那十五分钟几乎是一种冲击。
因为它第一次让我意识到：
原来软件还可以这样写。
后来发生的事情，现在回头看，甚至有些不可思议。
我从 Java 社区跑去了 Ruby 社区。
因为 Rails，我开始使用 Mac。
我加入了当时国内最早一批实践 Rails 的公司，也第一次真正接触敏捷开发。
然后是 Basecamp、37signals、Getting Real、REWORK、“小而美”、Remote，以及那个我很多年以后才真正理解的名字：
Signal v. Noise。
信号与噪音。
二十年过去了。
我本以为这些东西早已经成为过去。
直到最近重新坐在 Omarchy 面前，我才突然意识到：
它们其实从来没有过去。
它们早已经变成了我判断技术、产品、工作，甚至生活的方式。
这不是一篇关于我做过什么工作的回忆录。
如果一定要给它一个定义，我更愿意把它看成：
一个程序员二十年的技术品味形成史。
而 DHH，恰好一直若隐若现地出现在这条路上。
2005 年，我们都在学习如何把软件做复杂
2005 年的程序员世界，和今天完全不同。
那时候 Java 如日中天。
J2EE、EJB、Struts、Spring、Hibernate、XML、各种 Application Server……
一个刚进入行业的年轻程序员，几乎不需要思考应该学习什么。
那条路已经被铺好了。
学习 Java。
学习设计模式。
学习分层。
学习企业架构。
学习如何把一个系统拆成越来越多的层。
然后努力成为一个更加“专业”的软件工程师。
我也走在这条路上。
年轻的时候，人很容易把复杂误认为高级。
一个系统有更多层。
一个架构使用更多模式。
一个项目拥有更多配置。
一段代码用了更加抽象的写法。
我们会觉得：
这才像真正的软件工程。
那时候的我，还不知道所谓“技术品味”是什么。
因为你还没有见过足够多的东西。
你很难判断：
什么是必要的复杂性，
什么只是复杂性本身。
然后我看到了十五分钟 Rails
DHH 的那个 Rails 演示，真正改变我的地方，并不是“十五分钟可以写一个 Blog”。
而是它让我第一次看到：
很多我们习以为常的事情，可能根本不需要存在。
原来可以没有那么多配置。
原来程序员不需要时时刻刻向框架解释自己准备做什么。
原来一个框架可以先假设：
你大概率正在做一件正常的事情。
然后替你把那些正常的决定做好。
后来 Rails 有一句几乎成为软件开发常识的话：
Convention over Configuration。
约定优于配置。
今天再听，甚至已经没有什么冲击力。
但在那个年代，这对我的意义非常大。
它第一次让我意识到：
好的技术，不一定是给程序员更多能力。
有时候恰恰相反。
好的技术会替你拿走一些能力。
准确地说：
拿走那些你本来就不值得花时间思考的决定。
我现在回头看，可能就是从那个时候开始，我第一次产生了某种真正意义上的“技术审美”。
从 Java 逃到 Ruby
于是我开始从 Java 世界逃向 Ruby。
这里的“逃”当然不是说 Java 不好。
二十年以后再看，我对不同技术为什么会在特定时代出现，反而比年轻时候理解得更多。
Java 解决了那个时代非常真实的问题。
企业软件也有企业软件必须面对的复杂性。
但当年的我确实突然厌倦了一种感觉：
为了做一件本来很简单的事情，我们首先需要建立一个庞大的世界。
Ruby 给我的感觉恰好相反。
Ruby 的代码不像在描述机器。
它更像是在表达人的意图。
而 Rails 更进一步。
它不仅是一个 Web Framework。
它背后隐含着很强烈的价值判断：
程序员的时间是珍贵的。
程序员的注意力也是珍贵的。
如果一件事情可以通过约定推断出来，就不应该让每一个程序员重复声明。
今天我越来越觉得，这可能是后来很多技术选择的起点。
从那个时候开始，我逐渐少问一个问题：
这个技术还能做什么？
而开始问另一个问题：
为什么我要做这件事情？
这两个问题差别极大。
第一个关心能力。
第二个开始关心选择。
而所谓品味，很可能就是从“选择”开始出现的。
因为 Rails，我买了 Mac
今天回头看，这件事情甚至有点有趣：
一个 Web Framework，最后改变了我使用的电脑。
但当时确实就是这么发生的。
Rails 社区里大量开发者使用 Mac。
DHH 使用 Mac。
37signals 那种干净、克制、漂亮的产品气质，也和当时的 Mac 文化奇妙地重叠在一起。
于是我开始使用 Mac。
对于今天的年轻程序员来说，很难想象那个年代一个 Windows 程序员换到 Mac 是一种什么体验。
那不仅仅是换了一个操作系统。
更像是第一次意识到：
工具本身也是可以有品味的。
字体是什么样。
窗口是什么样。
动画是什么样。
一个按钮应该放在哪里。
一个界面到底应该出现多少东西。
一个软件应该如何对待用户。
甚至一台电脑打开之后给人的整体感觉，都可以成为设计的一部分。
Mac 对我的影响，并不只是让我成为一个 Apple 用户。
它让我第一次非常具体地感受到：
工程之外，还有设计。
而设计并不是装修。
设计不是把一个已经存在的东西变漂亮。
真正的设计首先是：
决定什么应该存在。
以及：
什么不应该存在。
第一次真正理解敏捷
因为 Rails，我后来进入了当时国内最早一批实践 Rails 的团队。
这也是我第一次真正接触敏捷开发。
今天再谈 Agile，很容易首先想到一套流程。
Scrum。
Sprint。
Standup。
Story Point。
Burndown Chart。
甚至有时候，一家公司可以把敏捷执行得比瀑布还要官僚。
但我第一次接触敏捷的时候，真正打动我的并不是这些东西。
而是一种更加朴素的观念：
软件不是一次性规划出来的，而是逐渐生长出来的。
先做一点。
看看。
再调整。
让真实世界不断进入开发过程。
不要假设自己在项目开始的时候，就已经理解了一切。
这件事情对我的影响很大。
因为它第一次动摇了我年轻时候对“工程”的某种迷信。
以前我觉得：
好的工程师应该尽可能提前想清楚。
好的架构师应该能够预测未来。
好的系统应该在开始的时候就拥有一个完整设计。
后来我慢慢发现：
现实不是这样的。
真正需要的能力，不是准确预测未来。
而是：
让系统拥有面对未来的能力。
这两个东西看起来很像，实际上完全不同。
前者试图消灭变化。
后者接受变化。
很多年以后，无论是理解 Rust、类型系统、边界、软件架构，还是今天做 AI Coding，我发现自己仍然在不断学习同一件事情：
不要试图控制全部未来。
把真正重要的约束表达清楚。
然后允许系统演化。
后来我发现，我真正喜欢的并不是 Rails
年轻的时候，我以为自己喜欢的是 Ruby。
后来我以为自己喜欢的是 Rails。
再后来，我才逐渐意识到：
真正吸引我的可能一直不是某个具体技术。
而是 Rails 背后的那套判断方式。
也是 DHH 和 37signals 对软件、产品、工作、公司、创业的一整套价值判断。
37signals 是一家很奇怪的公司。
它和后来硅谷逐渐成为主流的那套叙事并不完全一样。
不无限融资。
不把员工规模当作成功指标。
不把公司变得越来越大当作一种天然目标。
不认为所有软件都应该成为 Platform。
不认为公司存在的最终意义就是统治市场。
当整个世界都在讨论：
Grow。
Scale。
More。
Faster。
他们一直在表达另外一种东西：
Enough。
够了。
一个公司可以不用成为帝国。
一个产品可以只解决几个重要问题。
一个团队可以不用不断扩大。
一个创始人也不必把自己的整个人生献祭给一条永远向上的增长曲线。
中国后来进入了巨大的创业浪潮。
创业、融资、增长、用户量、估值、上市，逐渐形成了一套非常强大的成功叙事。
我当然也身处其中。
但 Basecamp 和 37signals 在我的脑子里始终留下了另一种可能性。
后来我们很喜欢用一个词：
小而美。
我不知道这个词能不能完全准确概括他们。
但它确实影响了我很久。
不是因为没有能力做大，所以安慰自己“小也很好”。
而是一个更加主动的问题：
即使我可以继续变大，大就一定是我要的吗？
“怎样做大”是商业问题。
“我为什么一定要做大”，已经开始接近人生问题了。
Signal v. Noise
37signals 那个影响了无数程序员的博客叫：
Signal v. Noise。
信号与噪音。
年轻的时候看到这个名字，我只是觉得它很酷。
后来才越来越理解，它几乎就是 37signals 所有思想的母题。
什么是 Signal？
什么又是 Noise？
刚进入行业的时候，我们总觉得：
知识越多越好。
工具越多越好。
Framework 越多越好。
Feature 越多越好。
配置越自由越好。
公司越大越好。
信息越多越好。
认识的人越多越好。
能做的事情越多越好。
但是活得久一点以后，你开始发现：
人生真正困难的地方，从来不是获得更多。
而是识别：
什么值得留下。
软件开发如此。
产品如此。
创业如此。
生活也是如此。
而噪音最危险的地方，是它通常不是垃圾。
真正毫无价值的东西，反而很好处理。
你可以直接扔掉。
真正难处理的是那些：
“也挺好的。”
“似乎有点用。”
“以后说不定能用上。”
“别人都在做。”
“既然成本不高，不如顺便做了。”
这个 Feature 也挺合理。
那个机会也不错。
这项技术也值得研究。
那个人也应该认识。
这个市场似乎也可以进入。
每一件事情单独看，都有理由。
于是我们不断把东西加进系统。
也不断把事情加进自己的人生。
最后发现：
我们非常忙。
却未必知道自己究竟在忙什么。
所以我后来越来越觉得：
Signal v. Noise 真正说的并不是：
做得少一点。
而是：
找到真正的信号。
我越来越喜欢“删除”
年轻程序员通常很喜欢创造。
加入一个抽象。
增加一个 Feature。
设计一套架构。
引入一个 Framework。
写更多代码。
这些事情都会产生非常强烈的完成感。
而随着年龄增长，我越来越喜欢另一个动作：
删除。
删除代码。
删除层次。
删除流程。
删除 Feature。
删除配置。
删除会议。
删除那些听起来不错、实际上没有那么重要的东西。
我甚至觉得，这可能是我技术品味变化最明显的地方。
年轻的时候，我通过一个系统“拥有什么”判断它是否高级。
后来我越来越喜欢通过：
它敢于没有什么
判断设计者的水平。
一个好的产品为什么只有这么几个按钮？
一个好的 API 为什么只暴露这些概念？
一门语言为什么故意不允许一些事情？
一个团队为什么决定不做某项业务？
一个人为什么主动放弃一个看起来不错的机会？
这些问题慢慢在我这里变成了同一个问题。
因为所谓设计，很多时候就是：
拒绝。
从 Ruby 到 Rust，看起来很远，其实没有那么远
后来我的技术路线走到了 Rust。
表面看，这几乎像是一次巨大的反转。
Ruby 是动态的。
自由的。
表达力极强的。
强调 Programmer Happiness。
Rust 却是严格的。
克制的。
甚至经常首先让程序员感觉“不自由”。
一个当年因为厌倦 Java 繁重而逃去 Ruby 世界的人，十几年以后，却深度进入了 Rust 世界。
但我越来越觉得：
它们在我的技术审美里，其实从来没有真正冲突过。
Ruby 当年教给我的，是：
不要让机器的偶然复杂性污染人的表达。
Rust 后来教给我的，是：
真正重要的复杂性，不应该依赖人的记忆来维持。
Ruby 在做减法。
Rust 在建立边界。
它们最终都试图做一件事情：
让程序员把自己的注意力放在真正重要的问题上。
Ruby 告诉我：
这些事情你不需要想。
Rust 告诉我：
这些事情你不能不想。
表面上完全相反。
但好的技术品味，从来不是追求所有地方都简单。
而是知道：
什么地方应该简单。
以及：
什么地方绝不能假装简单。
这是我从 2005 年走到今天，对“简单”这个词最大的理解变化之一。
真正好的简单，不是没有复杂性。
而是：
复杂性被正确地放在了该在的位置。
二十年后，DHH 又一次出现在我的电脑里
然后，时间来到了今天。
最近我开始深度使用 Omarchy。
我第一次认真把它作为日常系统使用的时候，很快就产生了一种奇怪的熟悉感。
这不是因为 Omarchy 里的每一项技术都很新。
恰恰相反。
它里面大量东西本来就已经存在于 Linux 世界。
Arch Linux。
Hyprland。
Terminal。
Neovim。
各种命令行工具。
各种开放的软件。
Omarchy 并没有发明 Linux。
就像 Rails 当年也没有发明数据库、HTTP、MVC 和 Web Application。
真正特别的地方还是：
有人替你做了选择。
Linux 从来不缺自由，它缺的是判断
Linux 世界一直拥有一种让我又喜欢、又疲惫的自由。
发行版可以选。
Desktop Environment 可以选。
Window Manager 可以选。
Terminal 可以选。
Shell 可以选。
Launcher 可以选。
Status Bar 可以选。
Editor 可以选。
字体可以选。
主题可以选。
每一个组件下面，又有几十种配置方式。
这当然是 Linux 最迷人的地方之一。
但自由还有另外一面。
每一个“你都可以自己选”，最终都意味着一个需要你自己做出的决定。
当这样的决定只有三个、五个的时候，它叫自由。
当它变成三百个以后，它就很可能开始变成噪音。
Linux 世界从来不缺优秀的软件。
很多时候，它真正缺的反而是：
有人愿意站出来说：就这样。
这个用这个。
那个不要。
快捷键这样。
窗口这样工作。
终端应该这样。
默认软件就这些。
它们组合起来以后，应该呈现这样一种体验。
不是说其他选择不好。
而是：
选择本身必须发生。
Rails 与 Omarchy，其实是同一种作品
我突然重新理解了 Rails。
Rails 当年最重要的地方，并不是它给了程序员多少能力。
而是它敢于替程序员做决定。
Convention over Configuration。
二十年以后，我觉得这句话后面甚至还藏着另外一句：
Opinion over Options。
判断优于选项。
好的工具，不一定应该尽可能把所有可能性都摊在用户面前。
一个真正有品味的工具，有时候应该拥有自己的判断。
它应该说：
我知道这里存在一百种做法。
我替你看过一些。
我替你踩过一些坑。
这是我认为值得留下来的组合。
先这样用。
先去做你真正想做的事情。
DHH 后来喜欢用 Omakase 来形容这种思想。
Omakase 最有趣的地方，并不是食材更高级。
而是：
你放弃了一部分选择权。
你坐下来，对厨师说：
交给你。
这背后是一种信任。
我相信你见过的东西比我多。
我相信你已经做过大量比较。
我相信你拥有自己的判断。
所以我不需要重新经历完整的选择过程。
Rails 是这样。
Omarchy 也是这样。
只不过二十年前，DHH 从 Web 开发的复杂性里挑出了一套组合。
二十年以后，他又从 Linux 几乎无限的可能性空间里，挑出了一组他认为最值得留下的东西。
于是我突然觉得：
Omarchy 本身，就是 Signal v. Noise 的一次操作系统级实践。
Omarchy：从 Linux 的噪音里捕捉信号
传统 Linux 世界几乎什么都有。
这是它最伟大的地方。
也是它最容易产生噪音的地方。
无数发行版。
桌面环境。
Window Manager。
Terminal Emulator。
状态栏。
包。
配置。
主题。
论坛。
Wiki。
帖子。
每个人都会告诉你：
“其实这个还可以换掉。”
“这个方案更轻。”
“那个方案更 Unix。”
“真正懂 Linux 的人应该自己配置。”
“你的 dotfiles 应该……”
信息没有错。
工具也没有错。
问题只是：
我的注意力最后去了哪里？
二十年前，Java 世界给我的疲惫是：
为了完成一件简单的事情，我需要处理太多原本不应该由我处理的复杂性。
二十年后，传统 Linux 世界给我的另一种疲惫是：
为了拥有一台完全属于自己的电脑，我似乎首先需要回答大量我其实并不真正关心的问题。
这两个世界看起来完全不同。
可它们给我的感受却非常相似：
噪音太多了。
而 DHH 做的事情，二十年似乎没有真正改变过。
他并不是不断给这个世界增加更多选择。
而是走进已有的巨大可能性空间里，
挑出一些，
删掉大量东西，
再把剩下的组合起来，
然后告诉你：
Try this.
我越来越觉得，这是一种非常稀缺的能力。
真正贵的不是创造，而是筛选
技术行业很长时间都有一种潜意识：
更多选择等于更强能力。
一个 Framework 支持 30 种配置，比支持 3 种厉害。
一个软件有 100 个功能，比只有 10 个功能厉害。
一个操作系统什么都允许改，比替你做了很多决定更自由。
可是到了今天，我越来越觉得：
当选择已经足够多以后，
继续增加选择的边际价值会迅速降低。
真正昂贵的开始变成另一件事情：
筛选。
判断。
组合。
删除。
以及有人愿意承担：
“我替你做这个决定。”
带来的风险。
创造一个选择不难。
面对一百个都不错的选择，只留下五个，才难。
这需要知识。
需要经验。
需要判断。
最后还需要一点很难量化的东西：
Taste。
品味。
二十年前，我因为 DHH 走向 Mac
这时候我突然发现，Mac 和 Omarchy 之间形成了一个非常有趣的圆环。
二十年前，因为 Rails、DHH 和那个社区，我开始使用 Mac。
Mac 当时让我第一次意识到：
电脑不只是硬件、操作系统和应用程序的集合。
它也可以是一件经过完整设计的东西。
有人替你决定字体。
决定窗口。
决定默认值。
决定交互。
决定什么应该暴露。
决定什么应该隐藏。
那种完整性，当年深深影响了我。
二十年后，我却又因为 DHH，开始认真回到 Linux。
这并不是因为我突然不喜欢 Mac 了。
而是通过 Omarchy，我开始在 Linux 上看到另一种我很喜欢的东西：
强烈而完整的个人判断。
它不像是一套庞大组织通过无数委员会讨论出来的系统。
更像一个同样写了几十年代码的人，
把自己这些年的工程经验、审美、习惯和取舍，
压缩进了一台电脑。
然后递给你：
这是我现在认为舒服的方式。
到了今天，这种东西对我的吸引力反而越来越大。
因为我已经不太需要一个系统向我证明：
“我什么都能做。”
我更想知道：
设计它的人究竟留下了什么。
以及：
他为什么敢删掉其他东西。
也许品味本身，就是一种压缩能力
如果今天让我给“技术品味”下一个定义，
我可能会说：
品味是一种压缩能力。
你见过足够多的东西。
你知道这里存在一百种可能。
但最后你能压缩成：
就这些。
没有经验的人面对十个选择，经常会觉得十个都重要。
真正经历过很多东西的人，反而可能越来越简单。
因为他知道：
其中九个并没有那么重要。
这也是为什么很多真正优秀的作品，最后看起来反而异常简单。
那不是因为设计者不知道其他可能。
恰恰相反。
是因为：
他知道得足够多，所以才敢删。
简单从来不等于无知。
很多时候，真正的简单是一种经历了巨大复杂性之后的压缩。
AI 让这个问题变得更加极端
然后 AI 来了。
这几年我越来越多地让 AI 写代码。
而 AI 又把这个问题推到了一个新的极端。
Rails 当年大幅降低了 Web 软件的创建成本。
AI 则把“创造”本身的成本继续往下推了几个数量级。
以前一个 Feature 是否值得做，还有实现成本帮你过滤。
一个人突然说：
“要不我们再加个 Dashboard？”
工程师说：
两周。
很多时候这个 Feature 自然就消失了。
但今天不一样。
你对 Agent 说：
做一个 Dashboard。
加搜索。
加过滤。
加图表。
再加导出。
十几分钟、几十分钟以后，它们也许都已经出现了。
于是曾经隐藏在工程成本里面的一个天然过滤器正在消失。
过去很多坏主意，会因为太贵而死掉。
今天不会。
AI 可以非常廉价地把每一个“要不顺便……”变成代码。
以前我们担心的是：
程序员写不出来。
未来可能更加值得担心的是：
程序员什么都写得出来。
AI 可以生成 Feature。
生成代码。
生成架构。
生成文档。
生成 UI。
生成 Agent。
生成测试。
生成方案。
甚至可以一次给你五套答案。
于是一个看起来很反直觉的事情发生了：
生成能力越强，Signal v. Noise 就越重要。
当 Generation 越来越便宜，
Judgement 就越来越贵。
当创造的能力逐渐接近无限，
真正稀缺的开始变成：
什么不应该被创造。
AI 时代，人可能重新变成 Signal Filter
所以我现在越来越喜欢用另一种方式理解未来的软件开发。
过去我们把程序员理解为：
代码生产者。
AI 时代，这个角色正在改变。
AI 可以越来越多地负责生成。
编译器、类型系统、测试和 Evidence 系统可以负责验证。
那么人最后还剩下一件极其重要的事情：
判断什么值得进入系统。
也就是寻找 Signal。
如果把它画成一个非常简单的过程：
现实世界有无限可能。
人先做一次判断。
留下 Signal。
AI 把这个 Signal 变成实现。
编译器、测试、类型系统再对实现做第二次过滤。
于是这里实际上存在两个完全不同的过滤器。
上面的过滤器负责：
价值。
下面的过滤器负责：
正确性。
AI 能够帮助我们创造越来越多东西。
但“什么值得创造”，依然是一个非常难的问题。
甚至可能比过去更加重要。
我终于理解，Rails 当年教我的究竟是什么
二十年前，我以为 Rails 教我的是：
怎样更快地开发 Web。
后来我觉得它教我的是：
Convention over Configuration。
再后来，我觉得它教我的是 Programmer Happiness。
到了今天，我反而越来越觉得：
Rails 真正第一次教给我的，是一个更加底层的东西：
人的注意力不应该被浪费。
不要让我处理不值得处理的复杂性。
不要让我做没有意义的决定。
不要把全部可能性都摊在我面前，然后把它叫作自由。
一个好的工具应该帮助我：
把有限的注意力留给真正重要的问题。
现在我重新坐在 Omarchy 面前，又看到了同样的东西。
二十年过去，DHH 真正影响我的可能不是任何一款软件
现在回头看，我已经很难准确说出：
究竟是哪一篇 DHH 的文章，
哪一版 Rails，
Basecamp 的哪一个功能，
或者 37signals 的哪一句话，
真正改变了我。
它们早已经混在一起。
Rails。
Mac。
敏捷。
Basecamp。
Getting Real。
REWORK。
Remote。
小公司。
小团队。
小而美。
Enough。
Signal v. Noise。
以及 DHH 那种几十年来始终非常鲜明，有时候甚至故意和整个行业主流保持距离的判断方式。
年轻的时候，我把这些看成很多观点。
后来才逐渐发现：
长期接触一个人的思想，最终真正改变你的，往往不是那些观点本身。
而是他的：
判断方式。
别人都在做，为什么我也必须做？
技术上可以做到，为什么就应该去做？
公司可以继续扩大，为什么就一定要扩大？
市场认为成功应该是什么样子，为什么我要接受？
一个系统可以给我一百个选项，为什么我要拥有这一百个选项？
所有人都在谈效率。
但效率最终服务于什么？
这些问题，最后慢慢进入一个人的直觉。
技术最终会变成一个人的性格
如果让我总结从 2005 年到今天的技术成长，
我现在已经越来越不愿意用：
掌握了多少语言，
用了多少 Framework，
做过多少项目，
来描述它。
因为这些东西都会过时。
Java 的时代来了，过去，又以新的方式回来。
Ruby 曾经站在聚光灯中央，后来慢慢退到一旁。
Rails 改变了整个 Web 开发世界，但今天很多年轻程序员可能已经无法体会当年的震动。
Mac 从极客圈里的选择，变成普通程序员的常见开发机器。
敏捷从一种反叛思想，变成了一整套企业流程。
创业从理想主义变成产业，然后经历一次次潮起潮落。
现在 AI 又在重新改写软件开发。
技术永远会变。
但有一些东西会留下。
我越来越相信：
技术最终会变成一个人的性格。
你喜欢什么语言。
你选择什么工具。
你如何理解软件。
你怎样看待复杂性。
你愿意接受什么默认值。
你什么时候愿意说“不”。
你如何面对增长。
你怎样分配自己的注意力。
时间久了，
它们慢慢都会变成你处理人生问题的方式。
2005 年，我看到 DHH 用十五分钟做了一个 Blog。
我以为自己看到的是一个新的 Web Framework。
于是我学 Ruby。
用了 Rails。
买了 Mac。
接触敏捷。
进入另一个社区。
然后开始读 Basecamp、37signals，开始接触一种和主流不太一样的软件、创业和公司文化。
二十年过去了。
我走过了很多技术。
从动态语言走到 Rust。
从自己写代码，到越来越多让 AI 写代码。
从 Windows 到 Mac。
然后现在，又重新坐在 Linux 面前。
中间有太多东西改变。
可今天使用 Omarchy 的时候，我突然意识到：
这里有很多东西，其实不值得你花时间。
简单。
并不是简单。
而是：
有人替你处理过复杂。
有人见过大量噪音。
然后从里面挑出了他认为最值得留下的信号。
我这二十年的技术成长，可能一直都是在学习同一件事。
在越来越嘈杂的世界里，
分辨信号，
然后，
让噪音过去。