聊一聊程序員的認知偏見

成長&認知 丨 做者 / 袁吳範

這是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年。從軟件開發、高級軟件開發、技術經理再到技術總監，分享職業發展、技術管理、職場晉升、技術成長等我的多年經驗和心得。一塊兒成長！

關注我↓↓，幫你答疑解惑！