完美主义 —— 软件工程生产力最大的阻力

news2024/12/27 12:19:18

此文大部分内容来自翻译，原地址在文末

在这里插入图片描述

简介

在毫无意识的情况下，完美主义常常让我们遭受损失。我们可能认为花这么多精力来确保结果是 “完美的” 感觉很棒的，但最终，我们永远不会达成完美，而我们的工作会变成无休止的“半成品”。

Jordan 关于完美主义的故事

在我职业生涯的早期，我花了很多时间编写代码。事实上，在我作为工程师的前3年，我发送了1200多个拉取请求（PR），平均每天约1-2个PR。

虽然代码量很大，但我当时关注的其实是一些错误的事情。大多数合并请求都致力于使我们代码库中的代码变得“完美”。

当时，我认为我在做伟大的事情。谁会不喜欢代码被 “打扮” 一下？但是回顾当时的时间，我意识到我没能很好地利用当时的时间。与使 “代码” 变得完美相比，我本可以为团队创造更多的价值，更何况很多代码是多年未被修改过且不需要被修改的代码

我当时可以做得更好的事情可以举一些例子：

与其让同事有很多的代码需要 review，不如减少代码提交和合并（那些美化工作）来让大家压力小一些。
更快地发布每个版本的功能
询问我的业务经理该做哪些事情以帮助业务

因此，我意识到当时这些代码提交与合并请求是多么毫无意义。如果我花更少的时间获得完美的代码，我可以减少 50% 的代码提交，并用这个时间为团队增加 x2 的价值。

今天，如果我在一周内不会发布超过 3 个合并请求。那是因为我的重点是做正确的事情，这通常意味着帮助团队、建立伙伴关系、写提案和通过文档扩展自己的影响力。当我发布代码时，必须对团队或者业务有明确的价值。

我通过做如下三件事来避免完美主义：

在一周开始时规划本周的高优事项，这有助于我知道本周完成哪些事情是最重要的。（而这些重要的事情，通常不是完善某事）
交付尽可能小的、有价值的产品或功能单元给内部或外部客户。例如，即使是一个只有80%功能完成的原型，也可以通过使用功能开关（feature flag）的方式先在内部发布，以便尽早获得反馈。这样做的目的是快速迭代，及早识别问题，并根据反馈进行改进，而不是等到一个功能完全完成后才发布。
在工作中我追求早期反馈。每天开始时，我会安排 四个小时的专注时间 来尽可能多地推进工作。之后，我会反思自己的工作：“基于我所完成的工作，有什么是应该分享或寻求反馈的吗？”。我会询问我的团队：“我的工作方向是否错误，还是我应该继续当前方案？”。有时候，我会发现比我的方案更简单的解决方案，或者发现问题已经被探讨过，又或者我的方案根本无法解决问题。这样做可以节省我大量的时间。

在这里插入图片描述

记住：更少的完美，更多的推进。

Gregor 关于完美主义的故事

完美主义从小就对我来说是个问题。我一直想把东西做得尽可能好，尤其是我看重的事情。

我花了很长时间才意识到这实际上是适得其反的。以下是作为软件工程师和技术经理我想要完善的事情。

我想从教程中“完美地”学习

在我作为一名自学成才的工程师的早期，我从在线教程中学到了很多东西。

回想那时，假如我不是总确保 100% 学完每一个教程，以及摒弃 “我不应该错过任何一秒” 的心态，那我当时应该会学的更快。

我现在知道，从教程中学习的最好方法是获取你需要的东西并将其应用到你自己的项目中。构建你自己的项目是最好的学习方法。

我想设计“完美”的东西

在学生时代，我也做了很多与设计相关的事情，比如设计横幅、平面设计。当时出现了某种重复的工作模式。

这种模式是，我会很快地创建一个草稿，然后花 2-4 倍的时间进行最后的润色。这既效率低下，又让我压力很大的。

我花了很多时间试图确保它“像素级完美”：正确的颜色、正确的字体、正确的行间距等等。如果我能接受不完美，我会取得更快地进展。有趣的是，完美主义的最终结果并不比初稿好多少（也许多一点）。

我想创建“完美”的代码

在我作为软件工程师的职业生涯早期，我会觉得我需要编写完美的代码，然后再展示给其他人。

我花了很多时间重构函数、重命名变量、重新思考方法并总体寻找优化方法。我的冒名顶替综合症总是让我觉得我不够好。（冒名顶替综合症—— Impostor Syndrome 是一种心理现象，指的是个人经常怀疑自己的成就，担心别人会发现自己不如外界认为的那么有能力、有才华。这种现象会导致即便有明显的成功证据，人们也会认为那是因为运气、偶然或者他人的过高评价，而不是自己真正的能力和努力。这可以导致焦虑和持续的自我怀疑。）

这让我整体效率变得很低，同时类似于设计 → 它给我带来了额外的压力。

如果我专注于 “足够好” 的代码而非 “完美” 的代码，并尽早获得反馈，我会取得更大的进步！