Newshot 文章标题：那些不再糟糕的坏主意
我从事软件行业大约 15 年了，这些年里我犯过很多错误，也从别人的错误中学到了很多。这份经验是一口深井，在讨论技术和非技术问题的可能解决方案时，我可以从中汲取。正因如此，我才知道哪些方案在理论上听起来不错、在实践中却会碰壁，或者哪个看似边缘的想法其实恰好适合我们要解决的问题。这些知识和经验在很大程度上造就了我作为领导者的有效性。
然而最近，很多我的直觉判断为坏主意的事情，结果却运作得非常好。在本周的团队回顾中，这一点对我冲击很大，对我来说是一个真正的学习时刻。它让我意识到，我一直依赖的很大一部分直觉可能不再像我以为的那么有价值，我需要更频繁地质疑那份经验。
所以我想写下几个我们目前正在做、实际上效果很好的“坏主意”，然后试着弄清楚这对像我这样的人意味着什么。
没有人审查别人的 PR
几乎在我整个职业生涯中，代码审查的方式都是一样的：一个人写代码并打开 PR，然后团队里的另一个人在合并前进行审查。第二双眼睛能发现 bug、在团队中传播知识，并防止任何一个人悄悄地把代码库带向自己的方向。未经审查就合并自己的 PR，属于那种“紧急情况下才打破玻璃”的事情。
大约一个月前，我们彻底改变了这一点。由于 PR 打开的速度加快，我们一直在代码审查上苦苦挣扎，于是我们决定尝试一件疯狂的事——干脆不做。现在，负责某个工单的工程师与 Claude 协作，由 Claude 打开 PR，然后负责该工单的人审查 Claude 的工作。一旦 CI 通过且 Greptile 审查干净，如果负责该工单的人确信解决方案是可靠的，他们就合并 PR。就这样。不用等队友找到时间切换到你的改动上，也不用在 Slack 里 ping 人请求看一眼。
而且效果非常好！当我真正思考它为什么有效时，原因在于代码审查原本防范的东西仍然得到了防范。每个改动仍然有第二双眼睛——只不过作者是 Claude，审查者是负责该工单的人。这个人比团队里任何人都更理解问题，因为他们就是一直在做这件事的人。对于那个改动来说，他们比一个必须从头加载所有上下文的队友是更好的审查者。而且，Claude 和 Greptile 就是更擅长发现代码审查中常见的那类问题，比如小 bug 或不一致。在这个阶段发现架构缺陷或意外的产品影响这样的大问题，是相当罕见的（至少在我工作过的团队中是这样）。
我以前写过，审查关卡可能是缺乏信任的信号，所以也许我不该对移除一个关卡奏效感到如此惊讶。但我的直觉仍然说“你不能没有别人看一眼就合并东西”，而我的直觉错了。至少到目前为止是这样——我们才改了一个月，但到目前为止感觉非常好。
把团队拆分到不同的工作流上
这就是我们在回顾中提到的那件事。最近我们有几个人休假，同时我们有几个并行且相当独立的工作流。所以我们把它拆分了，基本上每个人负责一个工作流并推进下去。
文章标题：那些不再糟糕的坏主意
正文： 过去我一直很不喜欢这种做法。当团队里每个人都在做不同的事情时，就会形成知识孤岛。只有一个人知道自己构建的东西是如何运作的，一旦这个人离开、生病或休假，团队就卡住了。更糟的是，我认为这会侵蚀真正作为一支团队的感觉。你们不再是一起解决同一个问题，而只是一群人在同一时间解决不同的问题，恰好共用一场站会。基本上在我带过的每一支团队里，我都反对过这种安排。
但在复盘会上，我们讨论了这件事，而我们并没有看到我担心的那些后果——至少在知识孤岛方面没有。原因是，如今要跟上别人的工作变得太容易了。如果我需要介入同事一直在做的事情，我可以对 Claude 说：“嘿，帮我跟上他们一直在构建的这个东西——它是怎么运作的，现在进展到哪了，还有什么需要完成？”几分钟后，我就有了开始贡献所需的一切。我不需要别人来给我做入职引导，也不需要花一天时间读代码来搞清楚状况。
真正发生变化的是，上下文切换的成本大幅下降了，因为我们是在比过去更高一层的层面上运作。我并不真的需要切换到具体的代码及其运作方式中去（或者至少开始上手时不需要那么多）。我真正需要切换进去的是问题本身。只要我对我们试图解决的问题有概念上的理解，并且大致知道我们要的方案是什么形态，我就能介入并发挥作用。
这种工作方式会不会有一些我们尚未看到的长期后果？也许吧！说实话我并不确定。但“也许有一个我们还没看到的问题”与我一年前会给出的论点截然不同，那时我会说：“我很确定这是个坏主意，我们会后悔的。”
不要深入
这一点与其说是关于我的团队如何运作，不如说是关于我给我管理的人的建议。
很长一段时间里，我对工程师在技术和职业发展上的标准建议是经典的“T 型”那一套。首先你建立起扎实的通用工程实践基础，然后挑选一两个领域深入钻研。成为性能方面的人，或者无障碍方面的人，或者分布式系统方面的人。或者选一个广泛使用的框架并成为它的专家——成为 Rails 或 Phoenix 的常规贡献者，通晓其运作方式的方方面面。这种深厚的专业能力过去是让自己真正有价值的最可靠方式之一。
现在我告诉人们的几乎正好相反。当你有了一位读过那个框架全部源代码、能在几秒内回答任何相关问题的协作者时，特定技术上的深厚专业能力就没那么有价值了。这是又一个（像我上面提到的）知识价值下降、但判断力仍然重要的例子。
我转而建议的是，仍然要在工程基本功上建立非常扎实的基础，因为我认为这正是我们人类目前能提供最大价值的地方。比如如何架构代码、如何设计好的抽象，以及如何判断一个抽象何时不再真正适用。是能够看着某个东西说“这开始变得有点薄弱了，我们应该把它拆开”，然后想出正确的抽象应该是什么。是注意到“这里似乎缺了某个需要命名东西”，并能够找到那个概念并为它命名。正是这些东西让高层架构、领域建模和数据建模保持高质量，也正是如今一名优秀工程师真正体现价值的地方。
但我也会告诉他们，技术过硬如今只是这份工作中很小的一部分。技术过硬已经不够了。你需要更多地了解设计。你需要了解产品开发，以及如何做产品经理，至少懂一点。你需要擅长与用户交流、做研究，并真正了解业务。
在我带领的团队中，我一直鼓励这样做。长期以来，我一直认为产品工程是做好这份工作的最佳方式。但我过去认为这是让人变得出色的因素，而现在我认为这只是基本门槛。只写代码或纯技术的人，其价值已经远不如从前，我不确定五年后这个行业里还能剩下多少这样的人。
我还在观望的另外几点
一旦我开始留意这些，就发现它们无处不在。以下是我尚未完全改变想法、但直觉已不如从前确定的另外几点：
从零重写。“永远不要做大重写”几乎是这个行业里的普遍法则。但重写之所以危险，很大程度上是因为它们耗时极长，而旧系统在你开发新系统的过程中还在不断变化。如果一次重写只需几天或几周而不是几年，很多风险就消失了。
自建而非购买。我曾劝过很多团队不要自建内部工具，因为已有 SaaS 产品能满足他们 80% 的需求。但当构建一个恰好满足 100% 需求的东西只需一个下午时，这笔账就大不一样了。
用三种不同方式构建。为同一个功能写三个不同版本、然后扔掉其中两个，过去显然是愚蠢的时间浪费。现在它往往是找出哪种方案真正正确的最快方式，而不是在设计文档里争论。我们可以跳过产品开发中的“粗略原型”阶段，直接在生产环境中用真实用户做 A-B 测试——如果愿意的话——这是质量高得多的测试，也能让东西更快上线。
引入团队里没人懂的语言或工具。“我们没人会 Rust，所以不该用 Rust”过去几乎是个无可辩驳的论点。我现在不那么确定了。当然，有些东西确实需要特定语言，比如我们在 Beat81 使用的某些软件需要与系统的某些部分对接。我们团队没有 C# 知识，但它也是我们想用的一个非常好的 ANT+/BLE 接收器唯一可用的驱动。
我真正错在哪里
把这些放在一起看，我觉得规律很清楚。每一件事之所以是坏主意，都是因为某种成本。我总是从成本与收益的角度思考问题。队友做代码审查之所以值得，是因为替代方案是根本没人看代码。知识孤岛之所以不好，是因为了解别人的工作需要缓慢且昂贵的上手过程。深度专业知识之所以有价值，是因为那种知识稀缺且难以获得。
AI 改变了很多这样的成本，而且改变得非常快。然而，建立在这些成本之上的规则并不会随着成本变化而自动更新，我的直觉也不会。我的直觉是在一个所有这些成本都相当稳定的世界里训练了 15 年形成的，所以它不断告诉我那些曾经正确的事情，带着一如既往的自信。
这就是这周复盘时真正触动我的地方。不是我某件事错了（我经常错）。而是我一直用来判断事情是不是好主意的那项技能（它在我职业生涯的成功中占了很大比重）现在给出错误答案的频率比过去高得多了。
所以我正在尝试改变自己的使用方式。当直觉告诉我某件事是个坏主意时，我会试着追问一句：当初让它成为坏主意的成本是什么，那个成本现在还在吗？有时候它还在，直觉依然是对的。但越来越多的时候，价值主张可能已经变了。对于过去可能会被我一口否决的事情，我现在确实更倾向于至少多做一些尝试。
在拿了15年薪水、至少部分是因为判断力好而获得报酬之后，承认这一点有点奇怪。但我认为，未来几年能做得好的领导者，是那些能把自己的经验握得松一点、愿意让团队证明自己错了的人。对每个人来说，这都是一个剧烈变化的时代，所以我们都必须适应。现在我认为重要的不是谁拥有最多的经验和知识（当然那仍然有一定分量），而是谁能最快地适应和学习，从而获得新的经验和知识。