耗费软件工程师时间和精力的 17 大心理陷阱
软件工程师通常认为错误是代码层面的错误。但在我们的职业生涯中，一些最大的问题来自于思维错误，而不是语法错误。这些错误并不明显。它们存在于我们的决策、判断和习惯中。
认知偏差和逻辑谬误决定了我们如何估计任务、判断他人的工作、选择工具以及从错误中学习。如果你没有发现它们，它们就会花费你的时间，误导你的思维，延缓你的成长，并伤害你周围的人。
这篇文章涵盖了 17 种偏见和谬误。有些是众所周知的。对于其他人，我相信这是你第一次听到它们。让我知道哪些对你来说是新的。
⭐ 在本篇文章中，您将了解到
- 为什么聪明的工程师会做出糟糕的估算，以及如何解决这个问题
- 如何发现代码审查、规划和技术选择中的思维缺陷
- 为什么即使需要改变，工程师也会抵制？
- 偏见如何影响我们评判他人和自己工作的方式
- 这些错误在日常工作中的实际例子
🧠 #1 规划谬误
计划谬误是一种低估任务所需时间的倾向，即使您以前做过类似的任务。
为什么会这样？这会导致错过最后期限和项目规划失误。工程师会承诺严格的时间表，最终在压力下工作，因为他们相信事情会顺利进行。
实际解释： 你可能会说某个功能需要 “一两天”，但却忘记了边缘案例、集成、测试和意外阻碍。即使前三个功能超时 40%，你仍然认为这一个会与众不同。
如果团队不考虑现实情况，项目就会偏离正轨。仅凭经验无法解决这种偏差。你需要深思熟虑，努力增加缓冲区，使用过去的数据，而不是直觉。
🔄 #2 XY 问题
当有人询问解决方案（Y）而不是他们试图解决的实际问题（X）时，就会出现 XY 问题。
为什么会出现这种情况？团队浪费时间解决错误的问题。讨论陷入无益的方向。
实际解释： 一位开发人员问：“如何在 bash 中合并两个 JSON 文件？”而实际问题是转换一个数据集。他们得到的帮助质量很低，因为问题隐藏了上下文。
优秀的工程师会提出明确的问题。不要认为别人提出的第一个问题就是真正的问题。深入了解他们想要做什么。
😰 #3 冒牌货综合症
冒名顶替综合症是一种信念，即尽管有证据证明你的技能，但你并不像别人认为的那样称职。
为什么会出现这种情况？工程师会隐瞒想法，避免担任领导角色，或在提出问题时犹豫不决。他们认为别人更聪明，知道得更多。
实际解释： 你每周都会交付生产代码，但在遇到一个棘手的错误或高级工程师提出意见后，你就会怀疑自己是否属于这个团队。你避免参与设计评审，因为你害怕自己听起来很蠢。
这种偏见限制了成长。人们会因为自己的沉默而学习缓慢，错失良机。事实上，即使是资深工程师有时也会有这种感觉。
📈 #4 邓宁-克鲁格效应
邓宁-克鲁格效应是指能力低的人高估了自己的技能，而专家则低估了自己的技能。
为什么会产生这种效应？初级工程师可能会过于自信，做出冒险的决定。资深工程师可能会过于怀疑自己，避免发表意见。
实际解释： 新开发人员可能会说：“这个应用程序接口应该很简单”，然后开始重构核心逻辑。与此同时，经验丰富的工程师可能会说：”系统的这一部分很棘手。
这就导致了早期阶段的过度自信和后期的自我怀疑。认识可以帮助你调整自信，提出更好的问题。
🔨#5 工具法则
这是指你对每个问题都过度使用你最喜欢的工具。
为什么重要？工程师会因为使用熟悉的工具而错过更好的解决方案。
实际解释： 您对 React 非常熟悉，因此您在任何情况下都使用它，即使简单的服务器端页面效果会更好。
选择工具要看是否合适，而不是是否舒适。扩展你的工具箱。
🪞 #6 自我服务偏见
这是一种将成功归功于自己，而将失败归咎于他人或运气的倾向。
为什么会这样？它阻碍了诚实的反思和学习。
实际解释： 你说由于你的巧妙设计，功能得以快速交付，但当功能延迟时，你却将责任归咎于会议或规格不明确。
责任感能帮助你成长。借口不会。
🧑⚖️ #7 基本归因错误
这是指人们倾向于指责他人的 Trait，而不是看背景。
为什么会出现这种情况？你会误判同事，错过问题的根本原因。
实际解释： 你认为队友粗心大意是因为出现了错误，而真正的问题是需求不佳或沟通不畅。
假设人们都在尽最大努力。修复系统，而不仅仅是修复个人。
🛠 #8 宜家效应
宜家效应是指人们高估了他们自己建造的东西的价值。
为什么会出现这种情况？工程师对代码情有独钟，即使在需要重构时，也会抵制更改。
实际解释： 你编写了一个自定义构建脚本。后来，有人建议用标准工具替换它。你拒绝了，不是因为它更好，而是因为它是你的。
这就减慢了改进的速度。评判代码的标准应该是实用性，而不是个人努力。
🚲 #9 骑自行车的人
舍弃是指在琐碎的细节上花费太多时间，而忽略了重要的问题。
为什么会这样？团队会陷入对简单问题的争论，而不是解决困难问题。
实际解释： 你在会议上花了 30 分钟讨论文件夹结构，却只花了 5 分钟设计数据模型。
注意团队的时间去向。不要把简单的讨论与有价值的讨论混为一谈。
🧑🏫 #10 权威偏见
权威偏见是指你过于重视高层人士或公认专家的意见。
为什么会出现这种情况？好的想法如果来自低级人员，就会被忽视。如果坏主意来自高层，则会被采纳。
实际解释： 一名员工工程师建议使用一种他们在生产中没有使用过的工具，团队就会不加质疑地照办。没有人愿意挑战权威。
头衔并不代表一个人就是对的。争论应基于证据，而不是资历。
🧍 #11 顺从偏见
顺从偏见是一种倾向，即使你不同意，也会与群体保持一致。
为什么会出现这种情况？工程师可能会在设计评审或规划会议上保留反对意见，从而导致决策失误。
实际解释： 一名新工程师注意到了拟议架构中的缺陷，但却保持沉默，因为其他人似乎都同意。
直言不讳会让人不舒服，但群体思维则会更糟。思想的多样性可以改善系统。
🧱 #12 这里没有发明（NIH）
这里没有发明是一种偏见，它反对使用外部解决方案，而倾向于建立自己的解决方案。
为什么重要？团队重新发明轮子，浪费时间构建已经存在的东西。
实际解释： 您没有使用稳定的开源库，而是构建了一个功能较少的内部工具。你的理由是 “这是根据我们的需求量身定制的”。
这将导致长期的维护成本和较慢的交付速度。在现有解决方案有效时使用它们。
🎉 #13 大军效应
跟风效应是一种倾向，即因为别人在做什么，自己也跟着做。
为什么会出现这种情况？工程师可能会为了跟风而采用不适合的工具或模式。
实际解释： 你采用微服务是因为 “大家都在这么做”，而不是因为你遇到了扩展问题。
时髦的技术可以奏效，但并非在任何情况下都能奏效。你需要问：”这能解决我们真正的问题吗？
🔥 #14 幸存者偏差
幸存者偏差是指只关注成功者，而忽视那些没有生存下来的失败者。
为什么会出现这种情况？你听说成功的初创企业使用了最先进的技术，并认为这是他们成功的原因。
实际解释： 你在一篇博文中读到一家公司使用 Rust 和 Kafka 进行扩展。你认为自己也应该这样做，却忽略了有 50 家初创公司曾尝试使用 Rust 和 Kafka，但都以失败告终。
不要局限于成功案例。问问哪些地方行不通，为什么。幸存者并不总是具有代表性。
🧠 #15 可用性启发式
可用性启发式是一种倾向，即根据你能多容易地回忆起例子来判断某事。
为什么它很重要： 工程师会根据最近的事例而非相关事例做出决策。
实际解释： 如果你最近修复了一个很大的缓存错误，那么你可能会在下一个项目中过度优先考虑缓存问题。如果上周某项服务出现故障，你现在可能会高估这种风险。
这会造成盲点。某件事情被放在首位并不意味着它很常见或很重要。
⚓ #16 锚定偏差
锚定偏差是指人们过于依赖他们看到的第一条信息。
为什么会出现这种情况？早期的估计、猜测或建议会扭曲以后的判断。即使它们是错误的，也会深深地印在我们的脑海中。
实际解释： 团队领导说一项任务需要 3 天时间。其他人都会从这一点开始思考，即使没有任何依据。这就成了锚。
你需要用真实的数据重新设定期望值。不要让糟糕的锚点影响你的计划或技术选择。
🔍 #17 确证偏见
确认偏差是一种倾向，即寻找支持自己信念的证据，而忽略与之相矛盾的证据。
为什么会出现这种情况？工程师可能会抵制有效的批评，挑剔基准，或过度相信自己的假设。
实际解释： 您认为框架 A 更快，因此您只测试框架 A 获胜的情况。而对于框架 B 性能更好的情况，则会忽略或不予考虑。
这种偏见会导致错误的技术决策和部落主义。对自己的假设保持怀疑，而不仅仅是别人的假设。
🎯结论
这些偏见不会出现在您的终端中。它们会出现在决策、代码审查、会议和计划中。如果不加以控制，它们会拖慢你的速度，损害你的团队。
开始在自己的工作中注意到它们吧。写出更好的估算。提出更好的问题。挑战你的第一直觉。用数据挑战你的团队。
其中哪些对你来说是新的？
