王媛滿

把一群程序員放在一起很多時候他們并不會互相學習，只有平時有共同理想，愿意嘮嗑，愿意一起解決難題，愿意聽對方的意見和分享的的一群小伙伴，才會在不知不覺中互相學習互相指導。

最近看了一本名字叫《程序開發(fā)心理學》的“閑書”，收獲滿滿，潤色一下分享給大家。

關于團隊的互相學習成長

我們經常都會說，要進入到一個高手比較多的地方去學習。身處一個高手遍地的地方，會發(fā)現人跟人差距就是這么大，而且高手做的事情你一點也插手不上，而且很多情況下也沒法學習到什么東西，很多時候高手最厲害的地方在于經驗和思維。如果只是在一個項目里邊分工合作，而除了干好自己的事情以外沒什么其他的目標了，那么很抱歉，你可能學不到什么東西。

書中有一段是這么說的：如果一個集體的共同目標僅限于產品的層次，那并不見得會促使其中的程序員互相學習。而反過來，團隊內部的成員不僅目標一致，而且其目標與他們具體開發(fā)的產品毫無關系，正是在這種目標的引導下，團隊的成員才會通過互相學習共同提高。

就本人的經驗來看，大部分程序員在一起工作并不會互相學習。如果是導師，那可能會有一些經驗的指導。如果是平級，那可能一年下來都不會互相學習。就算是經常有合作，很大可能性也只會在項目功能接口層面進行溝通。一方面是術業(yè)有專攻其他領域其實挺難去介入的，另外一方面可能思維上就沒想能從A項目、B項目和別人的產出上面學到什么東西。

但是如果，僅僅是如果，如果所有人都有一個評判標準，以及都有一顆想提高自己代碼質量的心，會進行代碼review。代碼review過程其實是能產生很多東西的，同時也能學習到很多東西，但是有個大前提，就是大家的對這個事情本身也感興趣，而不是為了具體的產品。根據以往的經驗，這種事情很快就流于形式，也就是隨便看一看，就算是精心準備的分享基本也都會被聽眾忽略掉，這就沒什么意義了。但是如果整個團隊對分享和代碼review這個事情本身很感興趣，還是能從中進行查漏補缺得到非常多的信息。

人類總會本能性地，反對別人對自己的負面評價。即使面對來自現實難以接受的反面證據，人們也往往會認定自己的程序完全正確。

“這不是bug，重啟一下試試?！?/p>

“這不是bug，絕對是使用方式有問題。”

很多時候人類都是會逃避對自己的任何負面評價的，無論這個評價是不是從很多人的角度看來都無可辯駁，畢竟計算機不會騙人，它只會做我們告訴它要去做的事情，但是人對它結果的解讀是帶有主觀性的。一個很好的功能，到了另外的場景可能就是bug。一個很難解決的bug，到了另外一個場景可能就是一個很好的功能。

有這么一個小故事，很久很久以前，我們的程序有一個bug總是找不出來，就是有一段內存總是會隨機性丟失。我們就開始查，拼命查，沒日沒夜地查，程序員走了一波又一波。但是依然都找不到這個問題所在，很是苦惱。突然有一天，咦，有一個地方需要模擬一個場景，就是內存隨機性丟失的場景下對程序進行測試。喔吼！這個帶“Bug”的程序比任何人為構造出來的內存丟失更加隨機更加可以反映事實，而且在很長一段時間里都非?！胺€(wěn)定”。

現在你還覺得這是一個Bug嗎？

關于團隊的高效

有些主管依然會與高效的程序開發(fā)團隊發(fā)生沖突，并進而又以各種毫不相干的借口，將這些團隊解散。而有些主管雖然還是搞不懂這些團隊的運行方式，但是他們卻至少懂得應該容忍這些團隊的存在。

在很多的職場，都會出現這么一個現象就是有其中一個團隊效率非常非常高，而且交代的事情也能完成得非常非常好，但是主管看不懂。他不明白為什么這幫人就行，另外一幫人就不行，也不是能力上的問題，因為大家都是同樣標準招進來的。

有的主管能很好處理，不理解就不理解，這些事情交給他們就穩(wěn)了，我對他們也愛護有加就行了。而有的主管則不能，就是希望掌控全局，任何一個小細節(jié)都不放過，對于這些超出認知范圍的事情很是“扎心”，一定要插一手，所以就出現了上邊的情況。

程序開發(fā)的社會效應

關于程序開發(fā)的社會性。比如程序開發(fā)中其中有一個環(huán)節(jié)就是程序員A口頭將信息告訴程序員B，這在以往的運行過程中得到了非常好地效果，這時候如果換掉程序員A或者程序員B，都將帶來效率的降低。

很多時候我們都以為我們的程序運行都是靠完美的產品設計，穩(wěn)定的系統(tǒng)流程，全鏈路能Cover住。很遺憾不是這樣的，我們處在的是人類社會，是人類在使用這些東西。只要有人類介入，那絕對存在一些很“迷”的東西。

比如，有一個功能開發(fā)好了，開發(fā)的第一反應不是去系統(tǒng)上點一下完成，而是大吼一聲：“測試大佬，我那個Bug修好了你驗收一下”。

又比如，很多程序員都會去找架構師聊事情，但是我們又發(fā)現有很多程序員坐在架構師旁邊的咖啡小屋那嘰嘰喳喳，所以老板決定把這個咖啡小屋干掉。好了事情來了，架構師開始忙不過來，大大小小的事情都找架構師解決。原來有這么一個咖啡小屋，大家看起來嘰嘰喳喳的很吵，但是其實大家在等架構師空閑的時候，已經在咖啡小屋把很多小事情討論完了，或者梳理出了一個比較可行的方案，這樣會節(jié)省架構師的時間，也會節(jié)省程序員的時間。

關于程序員的作息

一個老板看到程序員王鐵蛋早上十點才到，很是不爽，就跟程序員說啊我不管你明天要早點來。（其實程序員昨天晚上才把某個比較緊急的東西加班弄完到深夜）王鐵蛋的反映非常簡單，無非是嚴格按照工作時間正常地上下班。

還是希望小伙伴們，多去健身房，晚上確實要加班也可以，吃完飯健身完再繼續(xù)加，盡量十二點前睡下，過幾年你會回來感謝我的。

希望你們要克服人類的通病———假裝自己很努力。

關于民主和集權的領導模式

民主性集體。由于任務是全體成員共同承擔的，同時他們之間存在很多交流，所以當某個人離開后，其他的伙伴會根據需要填補它的空缺。但是反過來也證明，如果有一個新來的，由于組織中并不會給他留出一個特定的位置，所以這樣的團隊很難接受新成員。

集權式集體。任何成員離開后自然就會暴露出任務分工上的空缺，只有其領導者才擁有必要的信息能夠在剩余的成員中重新進行任務分配。但是如果有新成員加入，手續(xù)會非常簡單，直接去找領導人分配任務，然后交接就好了。

關于給項目潑冷水的人

會議上一片和諧，大家都對于接下來要完成的事情胸有成竹，開始小聲慶祝除了小喬，嘴上有一點點抿嘴。然而目光尖銳的項目負責人憑經驗還是察覺到了這個細節(jié)，問小喬：你還有什么問題嗎？

“一切都正常，但還是有一點點小問題。”

“有多?。俊?/p>

“我的任務可能需要延遲一點點。”

“多久？”

“六周?！?/p>

“我想……我的小組也需要這么久”，大喬說道。

“我也需要……”孫尚香、曹丕都順著說道。

這就是剛剛和諧開會的結果？我們剛剛浪費了一個小時在討論什么？

也許，需要有這么一個提出不同聲音的人，來質疑這個計劃以及那虛假的和諧，來保證這個項目的正常進行，很多開發(fā)對于程序開發(fā)中需要消耗的時間還是過于樂觀，覺得代碼寫完就完事了，又或者是對于項目本身不了解的盲目樂觀，這就是非常非常多情況下項目延期的原因。如果有一個人，指出這些方案的不合理性，又或者是項目時間的不合理性，可能就不會在項目延期的時候互相推諉了。

然而在現實中，這個人經常被當成噴子，被認為是來破壞和諧的人……

關于天才程序員

優(yōu)秀的程序員是培養(yǎng)出來的，不是天生的。

程序員其實現在都已經是一個門檻非常低的職業(yè)了，但是也存在跟數學一樣循序漸進的過程。要知道A定理，才會覺得B推論理所當然。如果不知道A定理，那么“大佬”在說顯然可得B推論的時候，你就會覺得很痛苦，這就是先前知識產生的壁壘。

程序員也是一樣，要知道足夠多、足夠底層的東西，你會發(fā)現現在所有的技術都只是在層上有一些封裝、拓展和易用上的改進，所玩的花樣基本都還是幾十年前的理論，沒什么大的變化。所以要像正常學習的節(jié)奏，去學習、去深究，去交流。當然無論是玩耍、游戲還是學習，只要覺得開心都可以去做，能在學習上覺得開心的肯定是少數，畢竟學習很多時候都是一件逆人性的事情。但是一旦克服了，恭喜，你已經比很多人厲害了。

所以你需要大量的練習。平時看到喜歡的東西，就去學就是了，就去練習就是了，管他什么跨界、什么太難，當玩具去玩就是了，再把它總結出來分享給大家，讓大家挑刺，有一天你很可能也會成為很多人眼中的“天才”。