我的很多讀者肯定會認為像我這種級別的人都是非常有思想、有決策力的大神。

[[356730]]

我會根據事情的真相，再三權衡，最后做出一個理性、正確的決定。

但，事實上基本上沒人能做到每一個決定都是理性而正確，即便是公司高管，我也不例外 。

其實我們的大腦在你不知不覺的時候幫我們做了很多決定。

這些決策都是基于不完善的信息和當時我們的心情，而忽視了關鍵的事實。

我們的大腦不是軟件，出現了bug，可以進行debug，最后找到錯誤的代碼。

但我們大腦卻在時時刻刻出現著bug，常見的bug就是認知偏見。

認知偏見有很多種，在Wikipedia列舉了大約90種常見認知偏見。

下面我會從認知偏見這個角度展示出程序員群體最常見的錯誤“代碼”。

讓你更加清楚了解這些偏見對我們思維和行動的影響。

1、思維定勢

給大家舉2個例子。

一、

19世紀中葉，美國加州傳來發(fā)現金礦的消息。許多人認為這是一個千載難逢的發(fā)財機會，蜂擁而至，許多不幸的淘金者不但沒有圓致富夢，反而被折磨得半死。有個叫默克爾的人，通過賣水卻在很短的時間靠賣水賺到幾千美元，這在當時是一筆非常可觀的財富了。

二、

我們公司大樓的2,3兩層是食堂，每次吃完飯。電梯口烏央烏央全是人，等著電梯，堪比擠東京的地鐵，像我這種中年發(fā)福的男人是擠不上去的。于是我就想了一個辦法，樓梯走到1樓，明顯感覺少了很多，只有零星幾個人，然后就非常容易的搭上電梯。

由此可見，當我們苦苦不得其解，其實只要稍微轉變下思維，問題就迎刃而解。

在項目的開發(fā)過程中，經常聽到有程序員跟我反饋，按需求上理解就應該這樣設計，領導給了規(guī)范就應該這樣。

程序猿在工作的過程中就非常容易受這樣或那樣的要求的限定，久而久之便形成了思維定勢，這樣的定勢一但形成就很難突破，本能的堅定的認為按照要求完成一定不會錯，不會錯但不一定是對的或最好最高效的。

因為你的領導也會受他們自己的思維所限，所制定的要求只是相對理想但永遠不會是最理想，這也是為什么所有的企業(yè)都提暢創(chuàng)新，想要創(chuàng)新最理想的狀態(tài)，需要我們每一個程序猿在工作中不斷的思考，不斷的突破，不斷的共享，不斷的修改規(guī)則和要求，從而才能實現創(chuàng)新，提高效率，與此同時你個人也會在這個不斷改變的過程中，收獲工作以外的成就感和價值感。

以我自己為例。

2015年的時候，我離開老東家，來到海康。

剛來第一個月里，一般情況下就是熟悉團隊氛圍和公司制度、文化的階段，而我發(fā)現代碼中的兼容性、擴展性都比較差，而且耦合特別大。就強制要求自己每天早上非常早的就來公司，晚上幾乎11、12點下班，在一個月時間內就輸出了一份軟件架構方案，遞到了領導的手上。

最后雖然方案還是有漏洞，但是大的問題沒有，在第二年就慢慢切換使用我設計的架構

原先的軟件架構一直問題比較大，為什么直到我的出現才完成了重構?

你可能會說，其他人的能力沒你強，心有余力不足。

但我覺得最大的問題是出在了思維定勢。團隊的每個人都習慣了這套代碼，只會想到怎樣去讓自己新增代碼更好的適配當前架構，并沒有聯想到重新設計架構。

2、以偏概全

極其不可能的巧合事件其實每天都在發(fā)生。

就2020年來說吧，從年初爆發(fā)的疫情，到全球經濟下行的壓力，大家都成為了歷史的見證者。

雖然這次疫情可能是人類歷史以來最為嚴重的疫情，但是拉到地球生命時間線上看，這樣的事件肯定并不少見。

我們會覺得很反常，因為在我們的記憶中或者我們父母的記憶中(甚至祖父母的記憶中)，這些災難從沒發(fā)生過。但是，這不意味著不會發(fā)生，也不能阻止它們一下子連續(xù)發(fā)生好幾次。

給大家一個數據。

美國人每年被雷電劈死的概率大概為600萬分之一。這個數字聽起來應該很小吧，但是仍然有幾十個人死于雷電。

再給大家一個數據。

美國人每年死于墜床的概率大概為40萬分之一。這個數字看起來也挺小的吧，而且你可能認為不算是危險的事情。雖然非常罕見，但每年都有上百人死于墜床。

這些事情都警示著每一個程序員，不要把未觀察到的、或者是概率及其小的事情認為是不可能。

任何你忽視的細節(jié)都可能讓你的軟件在未來的某個時刻出現莫名其妙的崩潰。

你應該在設計代碼時，仔細思考一下你可能遺漏的點，可能沒有想到的點。花時間檢查一下“不可能”異常值或者“極其不可能的”case。

如果它們真的發(fā)生了，你將會消耗10倍甚至100倍的時間和精力去解決它。

所以，記住：很少并不意味著沒有。

3、需要定論

對于沒有結局的電視劇，沒有找到真兇的偵探電影。

大家是什么感覺?是不是非常的不舒服。

其實這是我們大腦給我們強烈的信號，對于這種疑問和不確定性感到極不舒適。

我們會竭盡全力解決還未有定論的問題，最終得出結論。

但是你有沒有想過不確定性也是一件好事：讓你的選擇是開放的。

強行給出不成熟的定論，會迫使你放棄選擇，易于犯錯。

舉一個例子。

當領導交給你一個新需求時，你經過簡單的思考，就給出了開發(fā)截止時間，這就是嚴重錯誤。

你并沒有經過嚴格評估，沒有考慮項目內的不確定性，就草率的給出deadline，這其實一種自我掩飾，最終倒霉的還是你自己。

你應該怎么做?你可以告訴領導，這個需求工作量我會在半天內評估出來，然后會告知您每個細節(jié)的開發(fā)時間。

這樣的行為是不是更加有理有據。

所以我們需要適應不確定性。

在項目開發(fā)中，有太多的不確定因素，我們不知道項目究竟結束是哪一天。不知道是否有疑難bug暫時無法解決。有太多的不確定因素干擾著項目。

隨著項目的進行，這些不確定終于找到了答案，慢慢的走向確定。

難道我們就不能做點什么嗎?

當然啦，我們可以采取一些措施減少這種不確定。

例如，我們可以對需求進行詳細的設計，論證;可以對代碼進行嚴密的概要設計，等等。

雖然，措施多多少少有點作用，但是總是會遺漏，無法考慮全面，當然也就無法根治問題。

這不是壞事，這個從不確定到確定的過程，就是探索事物的過程，也是成長的過程。

最關鍵的是擺正心態(tài)，不要著急。

4、基本歸因錯誤

這個其實涉及到了心理學的概念，以下截自百度百科。

基本歸因錯誤描繪人們在考察某些行為或后果的原因時高估傾向性因素(譴責或贊譽他人)、低估情景性因素(譴責或贊譽環(huán)境)的雙重傾向。

什么意思?

就是人們傾向于把別人的行為歸因于他們的個性，而不去考慮行為發(fā)生時的場景。

舉個例子，比如A小姐，平時活潑、開朗，外向型性格，那么，如果有人告訴你她去喝酒應酬的時候喝多了，失態(tài)了。

你會認為這有可能發(fā)生，甚至會深信其一定發(fā)生過。

如果有人告訴你她見客戶的時候很害羞、很內向，倒水的時候手都緊張的發(fā)抖，你一定不會相信。

你會認為一個外向的人不會突然內向或特別緊張。

你會自然的認為外向型的人就做外向型的事，內向型的人就做內向型的事，這是一種偏見，其實，這是錯誤的。

還有一個更簡單的例子，人基本都會把面善的人認為是好人，而把面惡的人認為是壞人。

生活中，我們經常以貌取人，也是源自歸因的錯誤。

總的來說，基本歸因偏差又分三種。

一種是內部歸因，是指事情發(fā)生了，當事人會把所有問題指向自己。

外部歸因則是指事情發(fā)生了，當事人習慣把事情發(fā)生因素歸納總結為外部因素。

而綜合歸因則是事情發(fā)生了，當事人會內外綜合進行評價。

所以有的人他覺得自己從來不會錯，其實是指他是習慣性外部歸因，比如說他沒有升職或者原地踏步，他會責怪是自己沒有關系沒有背景，所以導致升不上去。

而內部歸因的人則習慣性把因素指向自己，比如同樣是升職沒有升上去，他會認為所有的問題都是發(fā)生在自己身上，因為自己不夠努力，人際關系不夠好，所以才導致自己不能升職。

總的來說，習慣外部歸因的人總是喜歡抱怨，最后容易變成憤青;

而習慣內部歸因的人則相對對自己較為苛刻，最后讓自己背負巨大的壓力。

所以我們要想最為客觀看待一件事情，我們必須學會內外結合，既采用綜合歸因，我們才能得到較為準確的信息，也才能更好的幫助我們自己成長，獲取更為立體的信息。

5、自私的偏見

在項目開發(fā)中，大家有沒有遇到這種情況。

有一些技術相對比較好的程序員在開發(fā)過程中會使用一些相對難于理解的技術實現，或者是一些語法新特性，也可能是一些新的庫。

往往使用這些技術開發(fā)出來的功能只有作者本人能理解代碼的邏輯實現，小組中的其他成員很難理解，甚至不理解。

這一發(fā)展形成了技術壁壘 因此別人無法去涉及這業(yè)務， 隨著業(yè)務的不斷發(fā)展, 壁壘就會越來越高。

雖然這種技術壁壘可以保證你在項目中的地位，但是這是自私的行為。

一旦這塊業(yè)務發(fā)生了bug，即使你忙的不可開交，你還是推卸不掉。

因為沒人懂，只有你去解決，別人根本幫不了你。

如果業(yè)務是經常變動的，可想而知你會多么痛苦。

更大的危害是，這中自私的行為阻礙了你的職業(yè)發(fā)展，因為技術壁壘不光阻擋了其他人的進入， 同樣也阻擋了你出去。

由于你無法從這個壁壘脫身，導致很多機會都給了其他人， 你只能眼巴巴的看著，時間久了， 你也只是成為了最熟悉這一塊業(yè)務的程序員而已。

我面試過很多工作5年左右的程序員，他們往往在一個業(yè)務上做了很久，但技術能力很是一般。

為什么呢?

因為他們對自己的業(yè)務熟悉了，太安逸了，在自己業(yè)務領域舒適著做個溫水青蛙。

最后一跳槽，原形畢露，毫無競爭力。

說到底是在自己負責的業(yè)務上設置了業(yè)務壁壘，殊不知是自私導致。

試問一下，如果新來的小伙伴問你業(yè)務代碼，你會不會耐心跟對方講解清楚，有沒有讓對方完全理解。如果沒有，其實你在建立自己的商業(yè)壁壘。

如果讀者你有這樣的行為，請立即停止，請丟掉自私心理。

你需要將自己的技術和業(yè)務經驗，毫無保留的分享給你的同伴或者下屬。讓他們能夠成長，甚至超越你。

當有新需求，或者出現bug時，你的同事能夠幫你分擔，能夠團隊協作。同時你有更多的時間接觸新技術提升自己。

還有一種人 ，如果項目成功，最大的功能都是他的，一直強調自己對項目的貢獻很大，而受到領導的不公。而項目一旦失敗，推卸責任，所有的失敗都與他無關。

這種行為，是一種個人防御機制，也是一種自私的偏見。

記住無論失敗，團隊所有的人承擔。

最后，既然選擇做程序員這條道路，自私的心理就應該丟掉。這樣才能讓你走的更遠。