教你用認知和人性來作最棒的程序員

不久前，在團隊內部和你們作了一次分享，內容就是此次要講的「用認知和人性來提高本身的技術水平」，你們反響不錯，因此此次整理一下也分享給你們。 最初我是想用「借優秀的產品經理思惟來作最棒程序員」的這個標題，但想一想仍是要有同理心，技術同窗平時和產品同窗已是相愛相殺了，就不刺激你們啦。可是必需要說的是優秀的產品經理思惟和優秀的程序員思惟確實是異曲同工的，二者是想通的，就是來自認知和人性。

這裏我不會過多去梳理認知和人性的概念，後面會用不少例子來講明，保證通俗易懂，只想先提2個概念：

1. 對人性的理解能幫助提高認知
2. 狹義的技術是指java,php,android,spring,vue等的掌握和實踐，它們只是幫助你提高認知的工具，卻毫不等同於認知。

下面我來逐一舉例說明

例子1-技術選型

• 問題：今年開始慢慢火的一個移動端跨平臺技術是google發佈的"flutter"，若是你做爲一名移動端的開發人員來評估這門技術是否值得選型做爲公司產品的語言框架，你怎麼能保證評估不會看走眼？
• 認知：flutter強化了跨平臺的生產效率，且性能比前端框架更好。
• 解釋：不少同窗會想，怎麼第一句感受就像廢話同樣，人家官方文檔也是這麼寫的，這叫什麼認知。別急，所謂的認知，就是可以提煉成外人看上去貌似一句很普通的話，但只有通過深度思考的你才知道它真正的價值。在flutter沒有出現前，我存在一個認知誤差，我認爲客戶端必定會被前端諸如react，vue這樣的技術取代。由於它們既能夠跨平臺，也能夠隨時更新，符合互聯網快速變化的節奏。但個人認知存在一個很是嚴重的漏洞，那就是跨平臺和隨時更新在客戶端技術裏的佔比各應該是多少？哪一個更重要？通過分析思考，以咱們公司當前用戶量的發展階段，提高跨平臺的生產效率且不損失太多性能更重要，所謂的運營快速需求變化有時候能夠經過事先想清楚，而下降頻率。 flutter帶來的生產效率提高，不只僅是一個開發能夠同時產出android和ios兩端應用。更在於產品經理之後只須要和一個開發溝通需求細節，不會再擔憂出現android和ios功能細節實現誤差的問題了。因爲有了這樣的認知，雖然flutter做爲新技術，還有須要完善的地方。但這不是主要問題，咱們願意爲它去冒險，在咱們的產品裏去儘快實踐。
• 人性：最後多說一句，爲何google先作了kotlin後又作了flutter呢？個人認知是：大公司兩個部門作重複輪子很正常，互相競爭，看誰更好。一個想試探性取代java以免被oracle捏住命脈（若是接受的人多，未來把底層的jvm再抽掉），一個野心更大但願統一全部平臺，不一樣部門的想法而已。你們不要把google的佈局想得那麼純粹技術化，你們都是人嘛。人脫離不了：競爭，征服，自保的人性。:)

例子2-查線上問題

• 問題：以爲查線上問題很痛苦，壓力很大，查得也不快怎麼辦？
• 認知：1 查線上問題是成本最小的，鍛鍊邏輯思惟的方式，相比寫代碼更有效率。 2 查問題要看本質，抓住案發第一現場
• 解釋：不少同窗碰到線上問題的時候，都很痛苦，由於要加班了耽誤我學習技術的時間，因此有時查問題態度也不積極。這個認知是很是錯誤的，你們平時都會承認優秀程序員的核心特質看的是思惟邏輯，而不是用哪一個語言哪一個技術。那若是是思惟邏輯優先，寫代碼就能比查線上問題更能提高嗎？顯然不是，你們知道咱們在寫代碼時，每每要花費不少時間在編寫冗餘代碼（如get,set代碼，配置文件），普通的crud邏輯，編譯，部署等這些非核心點上，它們並不能幫助咱們提高思惟（動手寫代碼前的思考纔是最核心的）。可是查線上問題就不同了，你不須要寫任何代碼，可是須要在很短期內，讓本身理清思路，按正確的步驟去查出代碼的核心問題，底層系統的核心問題。你須要對系統很瞭解，對業務邏輯很瞭解，對代碼細節很瞭解，這真是一個幾乎沒有任何冗餘步驟，可是卻能快速提高嚴謹思惟的好方式！ 怎麼讓查問題更有效率？其實很簡單，咱們若是借鑑名偵探柯南的想法，那就是「抓住案發第一現場」。舉兩個例子，對於JAVA這樣的靜態語言，查詢線上日誌的方法是很是重要的。不少同窗發現某個請求出問題了，就去看當次請求的日誌，這種方式不必定準確。由於對於靜態語言，它的案發第一現場可能已經不是當次請求了，頗有多是首次發生這個問題的時候，或者服務器剛剛啓動的時候（靜態語言的」緩存」特點）。當你發現上層的業務系統發生了mysql死鎖的報錯，就不要太糾結於上層業務系統的日誌了。應該去看mysql的bin log，抓住這個案發第一現場，看看到底發生了什麼。不知道怎麼解決線上問題，99%是由於連案發第一現場都沒找到，等你找到了，基本也有解決方法了。
• 人性：每一個人都喜歡作省力的事情，喜歡的事情。可是人每每有偏見，根本沒有想明白查線上問題的價值，就認爲這是一個很low的事，是不可取的。對本身不瞭解的，未知的事物，應該敬畏和學習。

例子3-技術面試

• 問題：不少同窗的技術經驗已經很紮實了，也能寫出很穩定的代碼，可是做爲技術面試官，爲何總是會看走眼呢？
• 認知：對應聘者而言，可否獨立解決問題是能經過面試的及格線，應聘者專業技術的掌握程度只決定offer薪資的高低。
• 解釋：是否是以爲又來歪論拉？恩，繼續解釋一番。首先問你，你爲何要招人，我想信不少人都會這麼說：固然是找你來幫我幹活啊，我如今每天干到11點，累死了，急需人幫忙啊。恩，因此你很清楚，這我的是要能獨立解決問題的，能幫你分擔的，不是來了還要你每天在那裏盯着的。可是咱們看到不少同窗的心裏認知是混亂的，雖然他能看懂這句話，可是在面試的時候他會這麼作：準備10個左右他擅長的技術細節問題，一個個問，應聘者只能答出5個，廢柴，不送。答出7個，恩，能夠進來。答出10個，還說了1個我不知道的，好牛逼，毫不能讓他看出來我比他弱，不然進來後還怎麼帶他。可是這個和你以前痛恨的應試教育又有什麼區別呢？這種招聘方式有很大的風險招進來的人是研究手機屏幕從幾樓摔下去不會碎，而不是研究讓屏幕顯示更清晰的人。 正確的方式應該是：讓他講一個以前投入度比較高的項目，描述下本身是怎麼獨立去解決問題的。對每個點的描述，只要你以爲還不能體現他「獨立解決問題」的能力，那就繼續扒皮深問，直到他不遺餘力，被你」逼到牆角」。特別優秀的人被逼到牆角後，具有現場把牆砸掉的能力，這樣的人是死也不能放過的，具體什麼意思你們能夠去體會思考。 以前咱們曾經面試過一個性能測試工程師，從技術細節看對性能測試的工具和方法是比較瞭解的。在項目描述中咱們問了他一個問題：你以前經過性能壓測發現的服務端問題，有去了解過發生的緣由嗎？他給的答覆是：由於咱們是外企，制度比較明確，開發也是另一個部門，因此我沒有去了解。很差意思，這個回答基本體現了沒有獨立解決問題的能力乃至意識。碰到一堵很小的牆，他都沒有辦法獨立解決，好奇和學習的慾望也很弱。他在技術細節上的積累只是由於看了幾本書，用了幾回工具，這些都只是爲了應付面試和不懂的領導，根本沒有深刻實踐，他將來的瓶頸必定很是大。 只要可以獨立解決問題，就必定能經過面試，有些技術不瞭解，最多就是被砍點薪資而已。在這一點上，10年工做經驗的同窗還真未必比得上2-3年工做經驗的同窗，若是沒有獨立解決問題的能力，那只是多累積了一些所謂的專業經驗，但仍是沒法解決問題。不少大公司喜歡校招優秀的畢業生，也是這個緣由，雖然這些學生尚未實際工做過，但已經具有了很強的獨立解決問題能力。咱們曾經招過一名同濟大學的測試實習生，有一次她獨立組織了部門的團建活動，搞得層次分明，方方面面都考慮到了，這樣的同窗作好技術只是時間問題。:)
• 人性：應聘者的人性有哪些呢？懶：影響獨立解決問題的意識。 要面子：好比剛剛舉的例子，拿公司制度掩蓋本身沒法獨立解決問題的現狀。（而且他本身是意識不到的，由於他心裏的認知是混亂的） 盲目自信又不自信：對本身作的熟的東西盲目自信，對沒接觸過的技術很不自信。

例子4-最嚴重的線上故障

• 問題：究竟是什麼緣由，會致使嚴重的線上故障呢？是咱們團隊的技術水平不高，仍是流程問題才形成了如此嚴重的故障呢？
• 認知：個體的過失很難形成嚴重的線上故障。真正的緣由是：集體性的認知出錯。
• 解釋：在現代微服務的架構下，各服務之間的解耦性已經作得很是好了，整體來講出現全面嚴重問題的機率已經降得很是多了。就像一個國家同樣，不怕局部的腐敗，怕的是整個鏈條的腐敗。舉個例子，若是一個系統上線前，須要在數據庫裏配置一個關鍵的參數，若是不配置會致使不少請求處理錯誤。可是開發同窗發生了錯誤的認知，潛意識裏認爲配置不是寫代碼=配置沒有寫代碼技術含量高=配置沒有寫代碼重要，最後把它忘了。測試同窗認爲測試配置不是測試新寫的代碼=優先測試新寫的代碼，再測試配置=測試代碼比測試配置更重要，最後把它也忘了。那這基本上是救不回來了，上線後必定會發生嚴重的問題，每一個鏈條的檢查機制都失靈了。堅定預防集體性的認知出錯，就能夠避免不少嚴重的問題。 集體性的認知出錯每每是從一些小現象開始的，好比咱們的團隊曾經發生過一次正常的項目延期，緣由是週五到了，沒有完成測試，爲了不倉促上線出問題，因此延期一天發佈。其實到這裏都是很是正常的，可是當測試同窗在釘釘羣裏發出這個緣由的時候，有一些同窗發出了大拇指的表情。注意，這個時候你們是沒有犯錯的，可是認知已經出現了誤差，變成了「之後就算測不完，只要說項目風險，就能夠延期」。羣裏不少同窗都看着，一旦這個集體性的認知誤差造成，將來項目的延期就會愈來愈多。因此須要馬上出來講一句：由於風險項目暫時不上能夠，可是延期的緣由要總結反思。 經過這樣一句讓你們內心不太舒服的話，儘快把集體性認知誤差扭轉過來。馬雲說過」小事要大作」，就是這個道理，不大作，等發生大事的時候就來不及了。
• 人性：盲目自信：對本身作的領域有自然的偏見，哪一個重要，哪一個不重要。隨大流：別人也這麼作了，應該不會錯，還省力，我也這麼作。懶：默守所謂的安全方案，其實在那個場景下已經不安全了，可是心裏認知出現誤差，懶得去破局改進。

例子5-如何看待代碼邏輯複用

• 問題：對於代碼邏輯的複用，你們的見解每每不同，有些同窗認爲只要是有公共性的代碼都該不斷抽出通用函數複用。有些則認爲對重要的通用邏輯才該複用，過分複用反而增長成本。
• 認知：能力該複用，業務不應複用。分久必合，合久必分。
• 解釋：這裏提出了兩個認知，咱們來分別解釋下。能力該複用，業務不應複用，這個很好理解。能力是指對這個系統有價值的功能，會長期存在且擴展下去的。而業務是一個泛指，既能夠表示單一的產品需求，也能夠表示某個局部的功能。好比你的應用裏接入了一個支付寶支付，對支付這個事情咱們判斷下來是一個基礎核心能力，且未來頗有可能也要接入微信支付，因此應該抽出公共的函數。再好比對於客戶端的登陸頁面和註冊頁面，雖然渲染邏輯90%是同樣的，可是不該該複用，由於它們是單一功能，不是能力，貿然複用反而帶來了很大的風險。 分久必合，合久必分，這個的理解就頗有意思了。你們都知道，這句話的出處來自三國演義，說的是一個國家分裂久了就會合並，合併久了也會分裂，其實對代碼邏輯的複用也是如此。你們在合併抽出公共函數時，會發現有10%-20%的邏輯不是那麼順眼，總感受暫時放在裏面是能夠的，但未來可能會拆出來。那麼在寫公共函數時，就要特別注意這部分邏輯。它雖然暫時在函數裏，可是須要作到和上下文相對隔離，甚至還能夠加入明顯的換行和TO DO，爲下一次的拆作好準備。而在拆出一些獨立邏輯的時候，也要思考這些邏輯可能和其它的哪些邏輯有機會是合起來的，那麼儘可能放在一個類裏，一個包裏，爲後續的合作好準備。
• 人性：不要刻舟求劍，妄圖用一套規則來應對外部複雜變化的世界，要因地制宜，實事求是，學會變通。

例子6-開源的意義

• 問題：爲何如今不少中國的互聯網公司開始重視開源的宣傳了？
• 認知：開源直接決定了公司的成本收入，以及人才儲備
• 解釋：是否是要崩潰了，開源無償寫代碼，而後免費給別人用，不是在消耗公司成本嗎？別急，還記得馬雲說過的一句話嗎，「免費的纔是最貴的」。恩，這個道理一樣適用於開源。今天中國不少的互聯網公司已經很是明白了，甭管你的開源技術到底好很差用，宣傳必定要大，必定要讓你們參與進來。 帶來的好處太多了，由於用了你的開源消息隊列，以後就會用你的雲計算平臺。由於程序員都很懶，開發環境和線上保持一套嘛，你後面必定能賺大錢。由於開源項目很是知名，讓你公司的技術形象馬上高大起來（先無論這個項目到底創造了多少有價值的產品），每一年校招的優質學生資源盡收囊中，其餘公司要搶人，只能花更多的錢。而每一年中國優秀的畢業生就那麼多，早就供需失衡，誰搶到了大部分，那以後在技術上必定能保持絕對優點。最後萬一公司財報很差看了，很差意思開始收受權費，就像google收android的費用同樣。不做惡只是口號，開源帶來了無比巨大的利益，不能賺錢，誰開源？！如今微軟也懂了這個道理，成爲了開源社區的標杆，但在早期的鮑爾默時代但是出現了認知誤差呢。
• 人性：開源者的人性：追求利益，喜歡聲譽。 接受開源的人：渴望進步，賺便宜，崇拜權威。

關鍵點：如何提高認知

心裏簡單：

心裏越簡單的人，未來能到達的境界就越高。你們千萬不要誤解了，我說的不是思想淺薄，而是心裏簡單純粹要像少年同樣。一個很好的例子，郭靖，用世俗的眼光來看他天資不高，開始學什麼都慢。可是他有一個很大的優勢，就是想法簡單，無私心，鍥而不捨。報家仇，報國仇，保護好他愛的人，不會去想是否是別人騙了他，他多作一點是否是虧了。20歲就達到五絕水平，最後終於融合「降龍十八掌」、「九陰真經」和「左右互搏」三大蓋世武功爲一體，武林尊爲「天下第一俠士」。 心裏越簡單，就越不會花費額外的精力在一些可有可無的事上面。隨着時間的推移，你的認知水平就必定能提高得更快。不要去想今天你學的語言明天是否還流行，先利用當前語言訓練好你的思惟模式。不要去想我做爲測試給開發指出太多問題後，開發會不會不爽，作爲測試你的核心是保證產品質量。不要去想今天我幫組內的開發分擔了額外的代碼編寫，我是否是虧了，這些付出必定會在未來某個時候兌現，由於你比他們有更多的代碼實踐。

相信跨界的力量：

ipod+手機誕生了iphone，手機+錢包誕生了支付寶，c,python+java誕生了go，人類的創新其實都是來自於跨界的結合。不少時候你們去看一個技術大神，會認爲他必定是看了不少專業的書，看了不少牛逼開源項目的代碼，寫了不少項目才達到如今的這個水平。而後又看到別人的興趣愛好：音樂，滑雪，畫畫，牛逼，大神就是大神，作好技術的同時還能「兼顧」這些興趣。 這個認知徹底錯了好嗎，我告訴你，寫代碼看書當然很重要，但若是他沒有這些興趣，他在技術上可能根本達不到今天的程度。一個有畫畫功底的人，理解向量，理解數據的PCA分析就是快好嗎。一個財務出身的人，寫支付系統的代碼就是不容易出錯好嗎。人類的大腦歷來都是一個網狀的，互相關聯的知識圖譜，根本不存在靠」單一事物」修煉成功的好嗎。千萬不要成爲技術上的孔乙己，每天學各類API的寫法，和學習茴香豆的茴字有幾種寫法沒有任何區別。在方案想不出來的時候，在代碼水平感受到瓶頸的時候，在看不懂一些專業書籍的時候，必定要跳出來，和本身的興趣結合，和本身經歷結合，和本身的生活結合，這樣才能突破瓶頸，提高到更上一層的認知。

相信更高認知人的指引：

科幻神做三體裏，外星人看地球人就像紙片同樣，在三體人的眼中，地球人是二維的，而不是三維的。回到現實中，高認知的人看低認知的人也是同樣的，不是低認知的人不夠努力，而是你的知識圖譜裏比高認知的人少了一些維度。因此無論你怎麼努力，你會發現仍舊沒法超過他，他還比你輕鬆，學霸給你們留下的陰影就是這麼來的。 在實際工做中，你的leader，你的架構師只要不是水貨，每每他們的認知就是比你高的。一旦你以爲這我的的本性是靠譜的，你就該無條件去相信他給你的建議和指引。由於他能看到在你那個維度上感覺不到的東西，照他的話去實踐幾回，你纔有機會到達他那個維度，才能升級認知。不過在現實狀況中，咱們每每看到不少leader和架構給下面的同窗苦口婆心說了不少，可是他們不理解，反而更叛逆。這份痛苦我懂，你是拼了命想拉他到你那個維度，可是他還年輕着呢。:)

鍥而不捨地實踐

人就是一個如此奇妙，如此複雜的生物，無論你看多少書，看多少源碼，寫多少demo，你不真刀真槍地去實踐，去寫代碼，這些知識不管如何都沒法進入你大腦的知識圖譜。它們永遠只能是「狹義上的知識」，而不是「有價值的認知」。相信你們人生中都有過相似的經歷了，越是辛苦的實踐，越是堅持，你最後的收穫必定越大。簡單來講，認知不經過鍥而不捨的實踐是不可能升級的。 還有一點我必需要強調，實踐應該儘可能和公司的項目去結合，而不是依靠於本身寫demo。這裏面有一個很大的誤區，本身私下寫demo常常是沒有「明確，高壓的」目標的（人性老是偏懶的），這種實踐每每很難提高認知。而公司的項目每每不一樣，會提出"支持多少用戶訪問"，「爲何你每次開發都不能更快一點」（核心挑戰的是你架構的擴展能力），「爲何這個功能這麼卡」（性能優化），這些「明確的，高壓的」目標能督促你去拼命提高本身的認知（只是寫demo是很難給本身設下這些障礙的，是反人性的）。固然從結果來看，又是公司的壓榨剝削拉，讓咱們回憶一下前面說的，若是你以爲這個公司是靠譜的，那就讓咱們的「心裏簡單一點」，鍥而不捨地實踐升級認知吧。:)

最後總結一下，如今已經不是一個單純比拼知識量的時代，而是比拼認知高低的時代。做爲程序員咱們並不特殊，和市場，財務，產品，運營的這些同窗同樣，核心看的是認知，並不存在誰比誰困難，誰比誰辛苦的這種淺層比較。 而咱們學習的那些語言，框架，工具，和咱們大學時期學習的微積分，高等物理沒有區別，都只是幫助咱們不斷訓練提高認知的實踐工具，而不是認知自己。讓咱們不要再侷限於程序員狹義技術的範疇內，把提高本身的認知做爲最重要的目標，咱們要努力作到「既是程序員，也不是程序員」。