先說兩句
這個易燃易爆的話題，其實俺是不敢寫的。在工程師隊伍裡濫竽充數了幾年，俺覺得自己還沒被清理和淘汰出去，已經謝天謝地了——不趕緊回去提高姿勢水平，居然還在這裡裝大尾巴狼，大言不慚地討論如何評估程式設計師，其心可誅啊。
那為何俺還要冒碼農之大不諱，在這裡妄議是非，大放厥詞呢？是因為俺發現，在日常工作中，對於一些非技術向的小夥伴們，由於對工程師文化了解並不多，要麼難以尋找到合適的技術夥伴，要麼在工作中與工程師難以保持穩定的溝通節奏，對於這些小夥伴，俺願意把俺知道的分享出來，膚淺也好，片面也罷，總之是多了一點參考，希望能有所幫助。
1. 對技術的分析和判斷力
技術沒有先進與落後之分，只有適用與不適用。如果你經常聽某個程式設計師對你說 “xxx 很先進，比 yyy 好多了，應該用 xxx 就不會有這些問題了”，“xxx 非常強力，BAT (此處可換為任何一個公司名) 的 yyy 專案以前用的是 zzz，現在都改用 xxx 了” 那麼就要對他的判斷力打個問號了。
下面是一些包含更多價值的例子，
- “xxx 雖然在 aaa 方面不太好，但比 yyy 更適合我們的專案，因為我們眼下更需要 bbb 和 ccc，將來如果在 aaa 方面出了問題，我們可以做這樣的調整： 1… 2… 3…”
- “我們之所以不用常規方案 xxx，而是用更激進一點的 yyy，是因為我們的專案在 aaa 和 bbb 等方面沒有那麼強的約束，雖然損失一些 ccc，但是可以獲得更高的 ddd 和 eee”
如果你發現一個程式設計師，行走都把某個特定的平臺/工具/技能/程式語言掛在嘴邊，“xxx 就是好啊就是好”，你就會知道他不僅有選擇上的侷限性，也會在技術判斷中不可避免的因為已有的積累產生偏見，正所謂“手裡握著錘子的時候，滿世界長得都像釘子”，一般這種程式設計師，俺稱之為“信徒式程式設計師”。
2. 對待預估任務時間的態度
誠實是一個重要的品質。相比起對他人的誠實，對自己的誠實就更難了。
舉個例子，你答應了兩個禮拜後交付一個版本，可是因為某些原因，一個禮拜過去之後，你發現自己還需要兩個禮拜，這時你會如何選擇呢？
誠實的態度是，承認自己的時間預估是不準確的，要麼砍掉一部分計劃，按期交付，要麼保證功能的完整性和質量，延期交付。如果一方面拍胸脯保證能按時交貨，另一方面罔顧負荷與節奏，過度地擠壓，就是不誠實的表現。這樣短期內能獲得更好的 KPI，但工程質量，團隊士氣都會受到打擊，長遠看得不償失。誠實餘額不足的協調者，慣用這種伎倆，通過各種手段，汲取和消耗組織的能量來為自己的 KPI 充電。更糟的是，這會使組織對團隊的能力做出有偏差的判斷，進一步放大問題，以致走上一條不歸路。
正確地預估任務時間，是一項需要經年累積才能有一點點成長和收穫的技能。任何一項任務，有經驗的開發者給出的不是一個拍腦袋的日期，而是包含以下諸要素的整體判斷：
- 完成核心功能需要的時間預估
- 完成次級功能和周邊工具鏈的時間預估
- 系統整合，穩定化，效能優化的時間預估
- 預留的緩衝週期
有經驗的程式設計師對計劃中的彈性點保持敏感，計劃會隨著實際進展不斷調整，不會刻板地拘泥於原計劃。他們的計劃會盡量做到誠實且忠實地反映實際的進展情況。如果突發情況造成了計劃外的影響，能及時地去做出調整，並向需要的人更新狀態。
3. 為自己的工作建立明確的邊界
所謂“明確的邊界”，就是能儘早地建立明確的頭腦模型，儘早摸清楚 (在你負責的領域內) 什麼必須做，什麼可以做，什麼不能做，什麼做不了。
有明確的邊界會帶來很多顯性和隱性的好處。最重要的好處是，大家的需求關係明確化、協議化，不再依賴私下的潛規則，會節省後續大量的溝通成本。其次，願意為自己的工作範圍建立明確的邊界的程式設計師，對邊界內的程式碼質量通常會有強烈的責任感和主人翁意識，他們會比其他人敏感和熟悉得多，在他們的地盤上，他們能徹底的說了算。相關係統內如果出了問題，讓其他人來可能要修兩三天，換他來可能憑著對相關程式碼的熟悉度閉著眼睛就說出幾個可能的問題點。
充滿各種潛規則的系統非常脆弱，如果你發現一個程式設計師總在焦頭爛額地處理溝通事務，往往就意味著隱患已經浮現出來了。缺乏邊界意識的程式設計師，往往伴隨著對程式碼較低的責任心。他們不把自己工作的程式碼看做是“自己的”，自然也就不會盡心盡力地去好好維護。
有種流行的說法是，應該通過某種形式的“輪換”，把程式設計師打造成“可輪換的”螺絲釘和多面手，以降低人員流失帶來的風險。也許這一方式對其他行業會很有效，但至少在遊戲行業，我發現，被這樣輪換的程式設計師，這樣來過幾次之後，確實是對彼此的系統更熟悉了沒錯，但他們變得不再像之前那樣“精心地”照料自己原本負責的那片程式碼。因為被 n 個人按自己的思路修理過之後，他們已經失去了“對那片程式碼的愛”，他們逐漸慢慢地從“園丁”變成了“遊客”。隨著時間的推移，沒有人對這個模組內部的所有可能狀態瞭如指掌，曾經被精心照顧的花園慢慢地變成了廢棄的垃圾場。每個人改到這裡都是無奈地捂著鼻子趕緊弄完了事，只要不要弄出新的問題就謝天謝地。這種腐化通常是加速而且不可逆的，從工程角度來講，這往往預示著這一堆程式碼的廢棄。更殘酷的是，程式設計師們紛紛發現在這個專案裡無法積累真正的領域相關經驗，成為專家，還有什麼比天天圍著一輛二手車的不同部位反覆修理又得不到成長更糟糕的事呢？他們唯一合情合理的選擇，就是拂袖而去，或是準備以溫和一點的方式拂袖而去。
程式設計師對程式碼的愛是一個專案裡最稀缺的資源之一，不要忽略它，更不要粗暴地碾碎它，要通過創造穩定的環境和氛圍去創造它，培育它，這樣的程式碼庫才能成為肥沃的土壤，帶來源源不斷的回報；否則就會變成一個搖搖欲墜、四處冒煙的，靠巧合來得以執行的龐然大物。
4. 對“異端”的相容度
「託利得定理：測驗一個人的智力是否屬於上乘，只看腦子裡能否同時容納兩種相反的思想而無礙於其處世行事。」
這句話有三層遞進的意思：
- 具有包容性。能夠理解矛盾各方的情勢，對盲點敏感，不容易被矇蔽。
- 具有批判性思維。能用理性和邏輯等工具去分析問題，形成自己的判斷，不盲從。
- 具有人格獨立性。依本性從事，不存偏見。
這三樣對於程式設計師來說，都是比較重要的軟素質。寸步不讓，主導意識強烈的程式設計師，往往有著驚人的自信——要注意這種自信有時會成為雙刃劍。在討論中展現出不必要的自信，往往在令人屈服的同時，促使對方從“奉獻者”轉變為“打卡者”，降低整個團隊的戰鬥力。
5. 對每一項提交記錄 (日常工作成果) 的態度
有經驗的開發者從一個程式設計師的提交記錄裡，能讀出太多的東西：
- 對於高素質的開發者，你能不費太大力氣就能順暢地讀出他近期做了哪些方面的工作；在哪些點上曾遇到了困難，選擇的解決方案是什麼；當他權衡和折衷時，考慮的最多的是什麼因素；在一段時間內，貢獻相對均勻 (DPS 能保持在相對穩定的節奏)
- 而相對的，如果你在提交記錄裡看到不少 “臨時方案”，“暫時先注掉”，“先跑起來晚點再改” 這樣的句式，或者提交資訊簡短到像發電報，或者提交一大堆程式碼卻不寫提交資訊，那麼這樣的程式設計師的實際貢獻意願和實際產出結果就要打個問號了。
檢視一個程式設計師的 commit history，一眼掃過去，如果除了 “完成了xx功能” “修復了 xx bug” 等資訊之外，還有一些 “改善了 xxx 的內部結構，方便後期維護”，“簡化了 yyy 的介面，降低了跟 aaa 和 bbb 的溝通負擔”，“自動化或移除了 zzz 的操作，省去了跟 ccc 的額外溝通和確認的步驟” 你就可以知道，這個程式設計師不僅業務能力過硬 (勉強能完成任務的程式設計師，是很難有餘力去操心這些事的)，而且對專案也有足夠的責任心和愛心，願意把自己的真正心血奉獻給專案，而不是想方設法總是湊合和應付，“先弄出來再說，哪管之後洪水滔天”。
其實，這也是最快的考察工程師團隊的一個方法——一個團隊的做事方式，效率，甚至是士氣和狀態，從 commit message 上能讀出大量的細節，而不少資訊是從平常的交流裡無法提取和判斷的。
6. 對待交付的態度
有經驗的程式設計師明白，提交功能的那一刻，只是交付的開始。這一點具體請詳見這一篇：不要說謊 (Don’t lie.)，這裡就不多說了。
7. 對待技術欠債的態度
一個快速前進的團隊不可避免地會留下或多或少的技術欠債，這是敏捷所要付出的最大成本之一。並非所有的技術欠債都需要償還，它們中相當一部分實際上會隨著開發風向的變化被直接風乾和丟棄。有經驗的程式設計師會時常為自己的日常工作留出處理技術欠債的時間，他們會及時查遺補缺，趁著手頭任務的餘溫，補上因為快速開發而遺漏的東西，同時果斷拋棄那些越積越重的包袱，儘量輕裝上陣。
如果你觀察到一個程式設計師總是樂於做新東西，他的提交記錄裡缺乏對已有系統的梳理和重構，那說明他更適合作為突擊隊員，還不能適應作為一個組織者的角色。
8. 對待人員流失的態度和處理方式
有經驗的程式設計師永遠不會故作驚訝，對同事或下屬的離職假裝出驚訝的樣子。他們總是“Work for the best, prepare for the worst”。他們在過去的經歷裡吃過虧，明白“靠山山會倒，靠人人會跑”，所以早在一個生力軍加入自己負責的團隊之前，他們就會計劃好此人一旦離開時的善後處置工作。他們不會輕易讓自己的團隊沒有原則地進人，也就不會讓自己負責的業務因為某一個人的離職變得失控。
但這絕不是在說他們對人員流動無所謂，不會主動捍衛自己團隊成員的利益。正相反，他們會重視每一個做出貢獻的成員，竭盡所能地為他們爭取應得的尊重；他們會把哪怕只貢獻過一行程式碼的離職同事都仔細地整理出來，放在 Credits 裡的合適位置，以確保他們的工作得到認可；即使某些成員在自己負責的團隊內表現不佳，當這些成員離開時，他們尊重個體的選擇，並仍願意給予力所能及的最大的幫助，因為他們清楚地知道，同一個人在不同的環境下，也有可能激發出完全不同的能量。
進階閱讀
讀完這一篇以後，如果覺得俺寫的水分太多沒什麼卵用的話，可以移步這裡，讀一下這篇進階讀物，“What makes a good lead programmer”。
嗯，差不多就是這些吧。對於還在尋覓中的小夥伴，希望這些文字能夠幫助你更好地判斷，鎖定和捕捉適合自己的野生程式猿 O(∩_∩)O~~ 而對想多瞭解一下工程師的小夥伴，也希望能促進幾分彼此的理解和包容 <(￣︶￣)>
不說了，我先去搬磚了~~
[2015-11-07] 補：
有同學提到，
有些地方不敢苟同，技術還是分先進和落後的，例如百度推送和個推
這裡俺說明一下，“推送和個推”是技術，“百度推送和個推”是百度對這個技術的理解和實現。用後者的質量來衡量前者的好壞，是常見的誤會。當然了，新的技術總會逐漸取代老的技術，這個是發展的必然，所謂“技術沒有先進落後”，著眼點在於“平等而不含偏見地”對待各種技術，以“是否適用具體情況”來擇而用之。