为什么我们总是抱怨公司的代码库是一坨屎山？为什么管理层总是对重构提议视而不见？Catalyst Monitor 的这篇 The perfect codebase won’t save your company 直击灵魂地回答了这个问题：市场奖励的是速度和执行力，而不是完美的工程。
文章核心观点
市场不关心你的代码质量
现实是残酷的，拥有糟糕代码库的公司依然可以赚取数十亿美元。对于大多数公司而言，它们的生死存亡并不取决于代码写得有多漂亮。软件市场的“赢家通吃”效应
软件行业具有独特的规模效应。因为分发成本极低，只要产品比竞争对手好一点点（或者快一点点），就能迅速占领市场。在这个“送披萨到全球任何角落”的比喻中，用户只会选择最好的那家。因此，速度至关重要。竞争的本质是寻找生态位（Niche）
在找到产品市场契合点（PMF）之前，所有的代码本质上都是为了验证假设。Slack 和 Discord 能共存，不是因为谁的代码更好，而是因为它们占据了不同的生态位。在市场被验证之前，重写代码的 ROI（投资回报率）极低。工程师的价值：增加尝试次数
既然市场是未知的，那么工程师最大的价值不是打磨一个完美的产品，而是赋予团队更多次尝试的机会，去击败竞争对手。
读后感与反思
这篇文章读起来可能会让有代码洁癖的工程师感到不适，但它揭示了商业软件开发的底层逻辑。
工匠精神 vs. 艺术家情结
文章引用了 Anthony Bourdain 的话：“好的厨师是工匠（Craftsman），不是艺术家。”
很多工程师（包括我自己）常常陷入一种“艺术家情结”，认为代码必须优雅、架构必须完美。但实际上，我们更应该是雇佣兵性质的工匠。我们的任务是用专业技能解决问题，而不是创作艺术品。
速度即质量的辩证
但这并不意味着我们要故意写烂代码。文章也澄清了一个误区：追求速度并不意味着放弃质量。
优秀的工程师通过编写可维护的代码、遵循 YAGNI（You Aren’t Gonna Need It）原则来提升速度。因为烂代码会拖慢后续的迭代，而好代码能让我们在未来改得更快。这里的关键在于平衡：为了“将来好改”而写好代码，而不是为了“现在好看”。
完美是完成的敌人
在创业初期或探索新业务时，完美的代码库往往是一种浪费。因为那段完美的代码可能连同整个产品线在三个月后被砍掉。 Casey Neistat 提到 BEME 被 Snapchat 的 Stories 功能截胡的例子非常生动：用户不在乎你是先想到的，也不在乎你的代码多牛逼，他们只在乎谁先发布了好用的产品。
总结
作为技术人员，我们需要跳出 IDE，去理解商业运作的规律。当我们不再执着于“代码的完美”，而是关注“交付的价值”和“迭代的速度”时，我们才能真正成为公司的核心资产，而不是仅仅被视为“写代码的人”。
拥抱不完美，用技术加速商业验证，这或许才是高级工程师的成熟标志。