为什么你应该选择无聊的技术
Choose Boring Technology (2015)
我在 Etsy 的经历让我深刻意识到，每个公司拥有的创新资源其实非常有限。与其在技术选型上盲目追求新颖，不如拥抱那些成熟、稳定且被充分理解的“无聊”技术，如 MySQL、Postgres 或 Python。盲目引入新工具带来的运维成本和认知负担，往往远超其带来的边际收益。真正的工程自由并非来自随意选择工具，而是通过克制技术欲望，将精力集中在解决业务核心问题上。当然，这并不意味着永远拒绝新技术，而是要求我们在引入任何新工具前，必须经过全团队的审慎讨论，并明确迁移计划。
你的工作本质是将业务问题映射到包含软件选型解决方案的空间中。
HN 评论区
240- NickNaraghi
假设每家公司大概只有三个“创新代币”。你可以随意花掉它们，但供应总量在很长一段时间内是固定的。
这是我非常喜欢的一篇博客文章，其核心思想基本上可以概括为“创新代币”。这是我作为产品经理/工程负责人职业生涯中遇到的最有用的概念之一。它有助于做出正确的权衡，更有助于向各个层级的同事解释这些权衡。强烈推荐。
- theptip
我很爱这篇文章。在智能体（agents）时代重读它，也很有意思。
用文章里的话说，我倾向于认为“把你们所有的创新代币都押在智能体上”可能是个明智之举。这意味着智能体所依赖的技术栈应该全部是“无聊”的技术。
换种说法就是“使用分布内（in-distribution）的技术”。如果智能体在 Rust 上的表现明显优于 Zig，那你可能就该用 Rust，哪怕 Zig 本身更“好”。Zig 好那么一点点，完全会被“分布内智能体”带来的巨大优势所淹没。
（这并非声称 Rust 真的更好，只是为了讨论而假设的一个事实场景。）
- insanitybit
尽管这篇文章很受欢迎，我还是想反驳一下。我不喜欢这个随意的“创新代币”概念，我觉得整个概念模糊了界限，感觉有点不严肃。
工程师应该理解需求、风险、权衡和潜在收益。新技术可能正是合适的选择。新颖的方法也可能正是合适的选择。“新颖”或“新”只是代理指标，而且很弱。
例如，我可能认为“新”意味着未经测试，但这真的对吗？如果一个新项目有 Jepsen 测试、模糊测试套件、庞大的算力运行大量预言机测试等等呢？我应该说的是“选择经过充分测试的”，而不是“选择老的”——很多老软件测试得非常糟糕。
也许我认为“老”意味着文档更好，但真的是这样吗？很多老项目积累了大量疯狂的陈腐代码和奇异的边缘情况，且多年无人记录。
我们为什么需要这个比喻？“创新代币”有什么帮助？
如果你无法根据这些属性来评估技术，那你就不是一名严肃的开发者，“无聊”也救不了你。
坐下来，写下你的需求，确定候选方案，然后根据它们的适配度进行选择。“无聊”毫无意义，它是一个模糊的代理词。“测试充分”、“适合我们的用例的性能”、“开发者熟悉它”等等，这些才有意义。
> MySQL 很无聊。Postgres 很无聊。PHP 很无聊。Python 很无聊。Memcached 很无聊。Squid 很无聊。Cron 很无聊。
上面列出的每一个都曾经引发过令人捧腹又灾难性的故障……
- iand675
嗯，我还没试过在 HN 上发布这个，但鉴于有这样的反对意见，我想至少应该尝试分享一下：https://www.iankduncan.com/engineering/2026-08-07-getting-fr...
- Animats
这其中的一些观点可能是对 JavaScript 框架频繁更迭时代的反应。当时有太多的技术做着大致相同的工作。
它们多多少少都能用。
另一方面，IBM 进入集成电路领域晚了。他们拥有固态逻辑技术（Solid Logic Technology），这是一种自动化机械，用于将晶体管放入陶瓷基板以制造微小但独立的电路。这就是 IBM System/360 的动力来源。它能用，但让大型机价格居高不下，也让 IBM 错过了小型机市场。
当问题很难时，创新才更有趣。看看美国远程轰炸机的历史。B-29 很有效，但动力不足，满载起飞非常困难。因此，二战后，下一个发展是 B-36，它回答了“如果我们把 B-29 放大规模会怎样？”这个问题[1]。它拥有六个螺旋桨和四台喷气发动机（在设计周期后期才加入）。它像一艘天空中的驳船，但只要没人拼命想把它打下来，它就能工作。现在没有可飞行的飞机留存了。这就是“无聊技术”的路线。
之后是 B-47，它回答了“如果我们把喷气式战斗机放大到轰炸机尺寸会怎样？”这个问题[2]。B-47 全喷气、无螺旋桨。它需要固体燃料火箭助推器（！）来辅助起飞，还需要减速伞来辅助着陆。它极难驾驶；其操作速度和高度太接近“死亡角”（coffin corner），即失速和跨音速抖振交汇的区域[3]。现在也没有可飞行的飞机留存了。
然后是 B-52。新引擎……
- conrs
很喜欢这篇文章。出乎意料地充满争议；它没让我交到多少工程界的朋友。
- jason_oster
这条建议依然有效，但有一些注意事项需要牢记。我脑海中立刻想到的有两条：
1. 我曾为一家拥有大型 Cassandra 集群的公司工作，该集群主要充当分布式追加日志。这个角色对于 Cassandra 来说简直完美契合。当我们需要一个用于身份验证的分布式数据库时，我们决定使用 Cassandra，因为我们有内部专业知识（它是“无聊技术”），而且有一个可以暂时借用的集群。当我们需要一个用于键值服务的分布式数据库时，我们用了同样的逻辑再次选择了 Cassandra。Cassandra 存在许多问题，我就不细说了，但我可以说，偏离 Cassandra 的舒适区太远，把它推到了崩溃的边缘。因此我们经历了一些停机时间和糟糕的夜晚。有时候，光有“无聊技术”是不够的，你还需要“无聊的工作负载”来配合它。
2. 我是 Rust 的早期采用者。在 1.0 之前，大多数人都不确定这门语言能否成事。对我而言，我看到一个形式化证明助手被交到了程序员手中，立刻就能看出它前途无量。那时的 Rust 并非“无聊技术”。你可能会说现在它是了（针对某些用例）。采用那些能切实提升信心的闪亮新技术并不是风险。愚蠢的是，对熟悉（即“无聊”）但难以正确使用的那些技术感到舒适和自满。
- cliche
我希望有一个招聘板，专门列出那些在工程文化方面经过此类验证的公司。
太多工作被包装成“我们是实用主义者”，但当你入职后，发现只有 5 个开发者、50 个仓库，大部分工作都在讨论某个需求是否应该做成一个新的微服务。产品通常只是一个有 10 个实体的 Web 应用和一个 API。
假设这只是为了保住人们的饭碗吧。