我的很多读者肯定会认为像我这种级别的人都是非常有思想、有决策力的大神。

我会根据事情的真相，再三权衡，最后做出一个理性、正确的决定。

但，事实上基本上没人能做到每一个决定都是理性而正确，即便是公司高管，我也不例外 。

其实我们的大脑在你不知不觉的时候帮我们做了很多决定。

这些决策都是基于不完善的信息和当时我们的心情，而忽视了关键的事实。

我们的大脑不是软件，出现了bug，可以进行debug，最后找到错误的代码。

但我们大脑却在时时刻刻出现着bug，常见的bug就是认知偏见。

认知偏见有很多种，在Wikipedia列举了大约90种常见认知偏见。

下面我会从认知偏见这个角度展示出程序员群体最常见的错误“代码”。

让你更加清楚了解这些偏见对我们思维和行动的影响。

---

—1—

思维定势

给大家举2个例子。

一、

19世纪中叶，美国加州传来发现金矿的消息。许多人认为这是一个千载难逢的发财机会，蜂拥而至，许多不幸的淘金者不但没有圆致富梦，反而被折磨得半死。有个叫默克尔的人，通过卖水却在很短的时间靠卖水赚到几千美元，这在当时是一笔非常可观的财富了。

二、

我们公司大楼的2,3两层是食堂，每次吃完饭。电梯口乌央乌央全是人，等着电梯，堪比挤东京的地铁，像我这种中年发福的男人是挤不上去的。于是我就想了一个办法，楼梯走到1楼，明显感觉少了很多，只有零星几个人，然后就非常容易的搭上电梯。

由此可见，当我们苦苦不得其解，其实只要稍微转变下思维，问题就迎刃而解。

在项目的开发过程中，经常听到有程序员跟我反馈，按需求上理解就应该这样设计，领导给了规范就应该这样。

程序猿在工作的过程中就非常容易受这样或那样的要求的限定，久而久之便形成了思维定势，这样的定势一但形成就很难突破，本能的坚定的认为按照要求完成一定不会错，不会错但不一定是对的或最好最高效的。

因为你的领导也会受他们自己的思维所限，所制定的要求只是相对理想但永远不会是最理想，这也是为什么所有的企业都提畅创新，想要创新最理想的状态，需要我们每一个程序猿在工作中不断的思考，不断的突破，不断的共享，不断的修改规则和要求，从而才能实现创新，提高效率，与此同时你个人也会在这个不断改变的过程中，收获工作以外的成就感和价值感。

以我自己为例。

2015年的时候，我离开老东家，来到海康。

刚来第一个月里，一般情况下就是熟悉团队氛围和公司制度、文化的阶段，而我发现代码中的兼容性、扩展性都比较差，而且耦合特别大。就强制要求自己每天早上非常早的就来公司，晚上几乎11、12点下班，在一个月时间内就输出了一份软件架构方案，递到了领导的手上。

最后虽然方案还是有漏洞，但是大的问题没有，在第二年就慢慢切换使用我设计的架构

原先的软件架构一直问题比较大，为什么直到我的出现才完成了重构？

你可能会说，其他人的能力没你强，心有余力不足。

但我觉得最大的问题是出在了思维定势。团队的每个人都习惯了这套代码，只会想到怎样去让自己新增代码更好的适配当前架构，并没有联想到重新设计架构。

---

—2—

以偏概全

极其不可能的巧合事件其实每天都在发生。

就2020年来说吧，从年初爆发的疫情，到全球经济下行的压力，大家都成为了历史的见证者。

虽然这次疫情可能是人类历史以来最为严重的疫情，但是拉到地球生命时间线上看，这样的事件肯定并不少见。

我们会觉得很反常，因为在我们的记忆中或者我们父母的记忆中（甚至祖父母的记忆中），这些灾难从没发生过。但是，这不意味着不会发生，也不能阻止它们一下子连续发生好几次。

给大家一个数据。

美国人每年被雷电劈死的概率大概为600万分之一。这个数字听起来应该很小吧，但是仍然有几十个人死于雷电。

再给大家一个数据。

美国人每年死于坠床的概率大概为40万分之一。这个数字看起来也挺小的吧，而且你可能认为不算是危险的事情。虽然非常罕见，但每年都有上百人死于坠床。

这些事情都警示着每一个程序员，不要把未观察到的、或者是概率及其小的事情认为是不可能。

任何你忽视的细节都可能让你的软件在未来的某个时刻出现莫名其妙的崩溃。

你应该在设计代码时，仔细思考一下你可能遗漏的点，可能没有想到的点。花时间检查一下“不可能”异常值或者“极其不可能的”case。

如果它们真的发生了，你将会消耗10倍甚至100倍的时间和精力去解决它。

所以，记住：很少并不意味着没有。

---

—3—

需要定论

对于没有结局的电视剧，没有找到真凶的侦探电影。

大家是什么感觉？是不是非常的不舒服。

其实这是我们大脑给我们强烈的信号，对于这种疑问和不确定性感到极不舒适。

我们会竭尽全力解决还未有定论的问题，最终得出结论。

但是你有没有想过不确定性也是一件好事：让你的选择是开放的。

强行给出不成熟的定论，会迫使你放弃选择，易于犯错。

举一个例子。

当领导交给你一个新需求时，你经过简单的思考，就给出了开发截止时间，这就是严重错误。

你并没有经过严格评估，没有考虑项目内的不确定性，就草率的给出deadline，这其实一种自我掩饰，最终倒霉的还是你自己。

你应该怎么做？你可以告诉领导，这个需求工作量我会在半天内评估出来，然后会告知您每个细节的开发时间。

这样的行为是不是更加有理有据。

所以我们需要适应不确定性。

在项目开发中，有太多的不确定因素，我们不知道项目究竟结束是哪一天。不知道是否有疑难bug暂时无法解决。有太多的不确定因素干扰着项目。

随着项目的进行，这些不确定终于找到了答案，慢慢的走向确定。

难道我们就不能做点什么吗？

当然啦，我们可以采取一些措施减少这种不确定。

例如，我们可以对需求进行详细的设计，论证；可以对代码进行严密的概要设计，等等。

虽然，措施多多少少有点作用，但是总是会遗漏，无法考虑全面，当然也就无法根治问题。

这不是坏事，这个从不确定到确定的过程，就是探索事物的过程，也是成长的过程。

最关键的是摆正心态，不要着急。

---

—4—

基本归因错误

这个其实涉及到了心理学的概念，以下截自百度百科。

基本归因错误描绘人们在考察某些行为或后果的原因时高估倾向性因素（谴责或赞誉他人）、低估情景性因素（谴责或赞誉环境）的双重倾向。

什么意思？

就是人们倾向于把别人的行为归因于他们的个性，而不去考虑行为发生时的场景。

举个例子，比如A小姐，平时活泼、开朗，外向型性格，那么，如果有人告诉你她去喝酒应酬的时候喝多了，失态了。

你会认为这有可能发生，甚至会深信其一定发生过。

如果有人告诉你她见客户的时候很害羞、很内向，倒水的时候手都紧张的发抖，你一定不会相信。

你会认为一个外向的人不会突然内向或特别紧张。

你会自然的认为外向型的人就做外向型的事，内向型的人就做内向型的事，这是一种偏见，其实，这是错误的。

还有一个更简单的例子，人基本都会把面善的人认为是好人，而把面恶的人认为是坏人。

生活中，我们经常以貌取人，也是源自归因的错误。

总的来说，基本归因偏差又分三种。

一种是内部归因，是指事情发生了，当事人会把所有问题指向自己。

外部归因则是指事情发生了，当事人习惯把事情发生因素归纳总结为外部因素。

而综合归因则是事情发生了，当事人会内外综合进行评价。

所以有的人他觉得自己从来不会错，其实是指他是习惯性外部归因，比如说他没有升职或者原地踏步，他会责怪是自己没有关系没有背景，所以导致升不上去。

而内部归因的人则习惯性把因素指向自己，比如同样是升职没有升上去，他会认为所有的问题都是发生在自己身上，因为自己不够努力，人际关系不够好，所以才导致自己不能升职。

总的来说，习惯外部归因的人总是喜欢抱怨，最后容易变成愤青；

而习惯内部归因的人则相对对自己较为苛刻，最后让自己背负巨大的压力。

所以我们要想最为客观看待一件事情，我们必须学会内外结合，既采用综合归因，我们才能得到较为准确的信息，也才能更好的帮助我们自己成长，获取更为立体的信息。

---

—5—

自私的偏见

在项目开发中，大家有没有遇到这种情况。

有一些技术相对比较好的程序员在开发过程中会使用一些相对难于理解的技术实现，或者是一些语法新特性，也可能是一些新的库。

往往使用这些技术开发出来的功能只有作者本人能理解代码的逻辑实现，小组中的其他成员很难理解，甚至不理解。

这一发展形成了技术壁垒 因此别人无法去涉及这业务， 随着业务的不断发展, 壁垒就会越来越高。

虽然这种技术壁垒可以保证你在项目中的地位，但是这是自私的行为。

一旦这块业务发生了bug，即使你忙的不可开交，你还是推卸不掉。

因为没人懂，只有你去解决，别人根本帮不了你。

如果业务是经常变动的，可想而知你会多么痛苦。

更大的危害是，这中自私的行为阻碍了你的职业发展，因为技术壁垒不光阻挡了其他人的进入， 同样也阻挡了你出去。

由于你无法从这个壁垒脱身，导致很多机会都给了其他人， 你只能眼巴巴的看着，时间久了， 你也只是成为了最熟悉这一块业务的程序员而已。

我面试过很多工作5年左右的程序员，他们往往在一个业务上做了很久，但技术能力很是一般。

为什么呢？

因为他们对自己的业务熟悉了，太安逸了，在自己业务领域舒适着做个温水青蛙。

最后一跳槽，原形毕露，毫无竞争力。

说到底是在自己负责的业务上设置了业务壁垒，殊不知是自私导致。

试问一下，如果新来的小伙伴问你业务代码，你会不会耐心跟对方讲解清楚，有没有让对方完全理解。如果没有，其实你在建立自己的商业壁垒。

如果读者你有这样的行为，请立即停止，请丢掉自私心理。

你需要将自己的技术和业务经验，毫无保留的分享给你的同伴或者下属。让他们能够成长，甚至超越你。

当有新需求，或者出现bug时，你的同事能够帮你分担，能够团队协作。同时你有更多的时间接触新技术提升自己。

还有一种人 ，如果项目成功，最大的功能都是他的，一直强调自己对项目的贡献很大，而受到领导的不公。而项目一旦失败，推卸责任，所有的失败都与他无关。

这种行为，是一种个人防御机制，也是一种自私的偏见。

记住无论失败，团队所有的人承担。

最后，既然选择做程序员这条道路，自私的心理就应该丢掉。这样才能让你走的更远。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：

长按订阅更多精彩▼如有收获，点个在看，诚挚感谢