聊一聊程序员的认知偏见

成长&认知 丨 做者 / 袁吴范

这是pointers公众号的第27篇原创文章

个人不少读者确定会认为像我这种级别的人都是很是有思想、有决策力的大神。

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

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

其实咱们的大脑在你不知不觉的时候帮咱们作了不少决定。

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

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

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

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

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

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

---

做者简介：

大厂技术总监，分享职业发展、技术管理、职场晋升、技术成长等我的多年经验和心得。一块儿成长！

关注公众号pointers，回复：【网盘】，还可得到pandownload复活版，下载速度60M/S。

添加我微信pointersss，拉你进群，跟群里大佬，技术经理、技术总监、CTO交流。

1

思惟定势

给你们举2个例子。

1、

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

2、

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

因而可知，当咱们苦苦不得其解，其实只要稍微转变下思惟，问题就迎刃而解。

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

程序猿在工做的过程当中就很是容易受这样或那样的要求的限定，长此以往便造成了思惟定势，这样的定势一但造成就很难突破，本能的坚决的认为按照要求完成必定不会错，不会错但不必定是对的或最好最高效的。

由于你的领导也会受他们本身的思惟所限，所制定的要求只是相对理想但永远不会是最理想，这也是为何全部的企业都提畅创新，想要创新最理想的状态，须要咱们每个程序猿在工做中不断的思考，不断的突破，不断的共享，不断的修改规则和要求，从而才能实现创新，提升效率，与此同时你我的也会在这个不断改变的过程当中，收获工做之外的成就感和价值感。

以我本身为例。

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

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

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

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

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

但我以为最大的问题是出在了思惟定势**。团队的每一个人都习惯了这套代码，只会想到怎样去让本身新增代码更好的适配当前架构**，并无联想到从新设计架构。

---

2

以偏概全

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

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

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

咱们会以为很反常，由于在咱们的记忆中或者咱们父母的记忆中（甚至祖父母的记忆中），这些灾难从没发生过。可是，这不意味着不会发生，也不能阻止它们一会儿连续发生好几回。

给你们一个数据。

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

再给你们一个数据。

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

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

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

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

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

因此，记住：不多并不意味着没有。

---

3

须要定论

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

你们是什么感受？是否是很是的不舒服。

其实这是咱们大脑给咱们强烈的信号，对于这种疑问和不肯定性感到极不温馨。

咱们会不遗余力解决还未有定论的问题，最终得出结论。

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

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

举一个例子。

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

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

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

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

因此咱们须要适应不肯定性。

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

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

难道咱们就不能作点什么吗？

固然啦，咱们能够采起一些措施减小这种不肯定。

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

虽然，措施多多少少有点做用，可是老是会遗漏，没法考虑全面，固然也就没法根治问题。

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

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

---

4

基本归因错误

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

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

什么意思？

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

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

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

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

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

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

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

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

总的来讲，基本归因误差又分三种。

一种是内部归因，是指事情发生了，当事人会把全部问题指向本身。

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

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

因此有的人他以为本身历来不会错，实际上是指他是习惯性外部归因，好比说他没有升职或者原地踏步，他会责怪是本身没有关系没有背景，因此致使升不上去。

而内部归因的人则习惯性把因素指向本身，好比一样是升职没有升上去，他会认为全部的问题都是发生在本身身上，由于本身不够努力，人际关系不够好，因此才致使本身不能升职。

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

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

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

---

5

自私的偏见

在项目开发中，你们有没有遇到这种状况。

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

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

这一发展造成了技术壁垒 所以别人没法去涉及这业务， 随着业务的不断发展, 壁垒就会愈来愈高。

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

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

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

若是业务是常常变更的，可想而知你会多么痛苦。

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

因为你没法从这个壁垒脱身，致使不少机会都给了其余人， 你只能眼巴巴的看着，时间久了， 你也只是成为了最熟悉这一块业务的程序员而已。

我面试过不少工做5年左右的程序员，他们每每在一个业务上作了好久，但技术能力非常通常。

为何呢？

由于他们对本身的业务熟悉了，太安逸了，在本身业务领域温馨着作个温水青蛙。

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

说究竟是在本身负责的业务上设置了业务壁垒，却不知是自私致使。

试问一下，若是新来的小伙伴问你业务代码，你会不会耐心跟对方讲解清楚，有没有让对方彻底理解。若是没有，其实你在创建本身的商业壁垒。

若是读者你有这样的行为，请当即中止，请丢掉自私心理。

你须要将本身的技术和业务经验，毫无保留的分享给你的同伴或者下属。让他们可以成长，甚至超越你。

当有新需求，或者出现bug时，你的同事可以帮你分担，可以团队协做。同时你有更多的时间接触新技术提高本身。

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

这种行为，是一种我的防护机制，也是一种自私的偏见。

记住不管失败，团队全部的人承担。

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

---

我是袁吴范，程序员的职场导师，公众号：”pointers“；

若有疑问，欢迎微信撩我：“pointersss” 坑位有限，先到先得。

---

 推荐阅读（干货）

7年，从“游戏少年”到大厂技术总监的逆袭之路

程序员成为高级管理者的三次跃升

技术总监7年总结，如何进行正确的沟通？

---

从业7年。从软件开发、高级软件开发、技术经理再到技术总监，分享职业发展、技术管理、职场晋升、技术成长等我的多年经验和心得。一块儿成长！

关注我↓↓，帮你答疑解惑！