怎樣才能叫高階程式設計師？

Stephen Tobolowsky 在定義聯體三角形

“我真的開始對我在這裡做的事情感覺不自信了。如果我們都不知道高階程式設計師到底是個什麼樣子，那我又該怎麼朝這個目標努力？”

我們 Frontside 公司是習慣於每週二下午開個全公司例會的，會上大家談談上週取得的成績，併為下一週訂訂計劃。

在最近一次會議上，我們談到了最近要招一位高階程式設計師，大家一談到這個話題就都立刻激情爆發了。因為要提到對公司影響重大的事，非招聘新人加入團隊莫屬了，所以很自然的大家就開始各抒己見，熱烈地討論起我們要找的人到底應該具有什麼樣的資質來。

可是除了依靠直覺，一屋子的人裡卻沒有一個能夠把大家的想法歸納起來，到底要怎樣才能叫做“高階”。

當一位同事說出了文章開始我引用的那段話之後，我意識到我們已經迷迷糊糊地碰上了一個對於整個公司來說都非常重要的問題：我們無法為我們想招聘的角色下一個定義，也不知道我們該怎樣培養我們的程式設計師。

定義“高階程式設計師”的難題

就我個人來說，我是對“高階程式設計師”這個稱號非常懷疑的，尤其因為當初在我有了 9 個月的正規程式設計經驗，他們就為了給我漲工資而給了我這個稱號之後。

事實上，如果你找來兩個有經驗的程式設計師，讓他們分別描述一下他們心中的“高階”是個什麼樣子，我敢保證他們的答案會大相徑庭。

“怎樣才能叫高階程高序員”這個問題其實非常依賴於語境，而且彈性空間非常大，以致於在我們這個行業裡各個公司都可以給出任何自己需要的答案。

下面是一些身邊人給出的我親眼見到的關於“高階程式設計師”的定義：

• 有 15 年以上程式設計經驗
• 有 2 年程式設計經驗並且有非常好的學習能力
• 有 1 年使用一個非常熱門的框架的經驗，並且框架釋出時間要超過一年
• 一本技術書的作者
• 可以在白板上默寫出來某個電腦科學的演算法
• 寫過一個開源庫並且在公司裡用起來了

這些定義之間相差實在太遠了。但想想在我們的生活中，很多東西都是沒法下定義的，那又有什麼問題呢？

為什麼要費力下這個定義？憑直覺做判斷不好嗎？

當大家在會議上說出這個困惑時，大家實際上說的是我們並沒有非常清晰和可定義的標準來僱傭人、開除人和提拔人這個問題。大家說的對，事實上也就是這麼混亂。

更糟的是，我們的核心使命——培養程式設計師——完不成了，因為我們沒辦法幫他們設定出一條發展路線來。

“我一見到這個人我就知道他是個高階程式設計師”——這種說法揭示了另一個重大問題：“高階程式設計師”已經根深蒂固地成了一個偏見的有效載體。

把“高階程式設計師”作為供奉偏見的一種方法

當我們描述一個高階程式設計師應有的樣子時，我們都是根據自己的經驗和喜好來的，這就意味著這個詞已經有了非常強的主觀色彩。

當我們沒有明確具體的標準，只能憑著直覺來判斷一個人的資歷的時候，我們就沒有辦法不帶有偏見，但我們還是要做出判斷。當一個人同時申請幾份開發工作的時候，非常有可能有的公司認為他只是初級，有的會認為他是中級，還有的卻認為他是高階，當然大家都不會直說自己是怎麼判斷的。

作為招聘經理，當我們做出判斷的時候我們都會自認為非常正確，即使大家得到的結論相距甚遠。

這樣的結果就是不斷被加強的偏見會阻止一些人進步，最終導致“頭銜通貨膨脹”。在當今技術界，各種偏見都不可避免的偏向白種男人，那麼這種憑直覺做判斷的體系就更多的會傷害女士和有色人種。

為什麼大家還沒有解決這個問題？

首先給這個問題下定義就很難，因為它和工作環境的具體情況關係太大了。大多數公司領導人處理這個問題的辦法都是走著瞧，而最終解決方案也都是“差不多”就行了。

解決這個問題也沒有什麼動力，因為當定下明確標準之後，公司領導人靠直覺做決定的權力很大程度上就會被剝奪了，而且還要為做出的決定負責。有誰會主動做一件讓自己又要讓出權力又要背上責任的事呢？

加上問責

我喜歡被問責，我也非常習慣。我懂得在為某件事負責任的同時，實際上我的自由度也是非常高的。就是否僱傭某個人這個問題來說，憑直覺下的決定往往比依據清晰的標準做出的決定更容易讓人後悔。因為我們的直覺太容易受影響了，從我早上是不是忘了吃早餐，到那個人是不是能即興談起某個動畫片，都有可能。

問責也為我們開啟了改進之門。作為招聘經理，我的責任是打造一支有戰鬥力、快樂和能力互補的團隊。要不斷改進並且朝著這樣的目標努力，可以靠直覺，可以全憑運氣，但我們也可以建立一種先定義、再衡量、又問責反思然後再從頭開始這樣的迴圈，來保證我們通向最終目標。

問責可以幫助我們在通向未來的道路上完成從乘客到駕駛員的角色轉換。

始於責任

現在問題變成了：我們怎樣才能創造一種用於衡量資歷的可度量的標準，而不是用那些有明顯缺陷、象玩遊戲一樣的方法？

我能想到唯一相對公平的評判一個侯選人的方式就是問幾個關鍵問題：這個人的責任是什麼？他是怎麼完成任務的？他工作上需要什麼樣的幫助？

我們先從定義我們的情況開始了。當我們總結了 Frontside 的工作環境特徵後，事情就開始變得清晰：

• 公司很小，所以每個人都要肩負多種責任，承擔多種角色，並且要從頭到尾的跟進解決問題。在我們這臺機器上沒有居中的傳動齒輪。
• 我們依賴並打造內部社群的力量，以及我們參與的外部社群，尤其是開源界。
• 我們在技術目標和程式碼可維護性可用性上追求極致。

於是團隊成員的責任就非容易確定了：

- 可以為隊友及客戶提供清晰專業的技術和專案指導。
- 在內部和更大的程式設計社群裡可以輔導他人、教授並且做出貢獻。
- 可以很愉快的將軟體交接給使用者或者接手維護它的其他程式設計師。

所有這些責任構成了我們評估資歷的標準基礎。

聯體三角形：簡單的解釋

我恰好最近有機會與好幾家不同規模公司的負責人討論了“高階”的定義，大家意見的共同點只有一個。

大家最簡單的關於資歷的共同解釋就是：這個人需要多少指導？這個人能給別人提供多少指導？

我贊成這個“高階程式設計師的組合三角形”是一個不錯的主意，可以簡明的表達出內在含義，就象 Action Jack 的“成功的組合三角形”一樣。

但即使這樣的標準也是非常容易引入偏見的。它缺少一些重要的標準，並且過度強調了口碑這類容易見到的東西，以及解釋深奧的計算機術語的能力。

在會上我們討論出了一個新的框架

會上的熱烈討論有了一個非常酷的結果。在我試圖灌輸上面的三角形理論時，另一位員工提出了一個嶄新的心理模形，吸引了大家的注意力。

她把我們在 Frontside 確定資歷的方法描繪成了一個文氏圖（用閉合的區域表示集合的圖示法）。三個集合分別是：這個人有多強的獨立工作能力及領導力？這個人技術實力如何？這個人和外部環境關係如何、有多大貢獻？

文氏圖：更復雜的解釋

在上文中我們已經把對資歷的評估方法提升到了更高境界：“這個人需要多少指導？這個人可以給其他人提供多少指導？”但正像我們的員工指出來的，如果到此為止的話，還會有非常多令人困惑的地方。

那我們該怎樣定義一位候選人到底能把他的本職工作做得多好？我們怎樣能把評判標準引向一些具體的方面，而千萬不要變成數學公式？

我們最終按照候選人要做的事總結出了三方面：技術能力、領導力和交際能力，並細化提煉出了 12 個特質。我將在下一篇文章中詳細闡述這 12 個特質，但現在我可以簡單說說。

三大方面

技術能力（Technical capability）：技術能力強的人通常都對技術有濃厚興趣，他們會不斷鑽研決不放棄，最終會做出可供經驗不足的工程師使用、維護和學習的解決方案。

領導力（Leadership）：有領導力的人知道怎樣為自己及別人發展並保持一種目的感。他們會指出公司裡及自己職業生涯中出現的問題，並且攬到自己身上最終解決掉。

交際能力（Community/Connectedness）：交際能力強的人非常希望自己成為一個大集體中的一員，有非常強的奉獻意識，身上有別人（同事、客戶等）無法輕易描述的個人魅力，並且存在感非常強，生活充實快樂。

“對文化的適應能力”怎麼樣

我們最初差點把交際能力叫做“對文化的適應能力”了，但我非常懷疑這個定義實際上是個扼殺思想的陳詞濫調。“對文化的適應能力”就是一個萬金油，所有你想在程式設計師身上見到的可你又說不出來的東西都可以用它往上套，而且這裡面也非常容易藏入偏見。

當我們定義好了可以讓 Frontside 的文化一致的標準之後，上面的觀點就定義成了交際能力。

在三個不同方面衡量資質

還記得那三個方面嗎？技術能力、領導力和交際能力，每個方面都有自己的從初級到高階的發展路線。

現在人們換職業都不是什麼新鮮事了。很容易見到那些有很強領導力和交際能力但剛參加完程式碼訓練營的人，他們的技術水平就只能被認為是一般。相反，一個經驗豐富又受過正規培訓的技術人員卻有可能缺乏領導力和交際能力。

很少有人真的能在三方面都能達到高階水平，事實上也很少有人真的想在三方面都成為高階。我們 Frontside 把資質定義為這些方面的混合體，並努力幫助人們在他們想提高的方面獲得進步。

證據：唯一能得到的衡量依據

衡量每個方面的資質都需要證據。如果你已經做了一些工作，那你手上應該已經有了一些證據。

我們將在下一篇文章中討論這 12 個特質，每一個都有詳細的標準，可以讓候選人提供證據來說明他們經過時間的積累的確具有這些特質並且經驗豐富。

但總的來說，如果在某個方面有一兩項特別擅長和精通的特質的話，就可以認為他在那個方面是高階了。

比方說，假如某個人告訴你他的程式碼用好幾種語言實現過，那在“技術好奇心”這個特質上就可以得高分了。如果他還會非常嚴謹的為專案的核心程式碼寫出全面、高質量的測試用例並用於持續整合，你就差不多可以認為他在技術能力上達到了高階水平。

或者如果某個人經常輔導別人、組織聚會，或者會做一些讓大家過得更輕鬆的事，那我們就差不多可以在交際能力這方面給他打高分。

如果某個人曾經帶過幾個團隊，那他就應該已經掌握了帶團隊的技巧。再加上挖掘問題根本原因的能力，那你就可以認為他在領導力的方向上達到高階了。

我們怎麼定義“高階”

我們的衡量標準是如果某個人在技術能力上達到高階水平，他在領導力或交際能力中有一方面也能達到高階水平，我們就認為他是高階程式設計師了。如果他還想繼續提高剩下的一方面，我們願意提供幫助。

如果他是在領導力和交際能力都能達到高階水平，在技術方面能屬於中高階的話，我們也認為是高階程式設計師。

舉個一年前發生過的真例項子，我們僱傭了一個初級程式設計師，因為據我們評估，起碼在最初的六個月中他需要非常多的指導。

到了第六個月，他的技術水平就已經達到中級了。到第一年結束時他就已經達到了高階水平。我敢這麼說的原因是我們知道如果他離職，我們需要僱傭一個高階程式設計師來頂替他。

這樣的事情為什麼能發生？因為他是在我們公司起步的，而當時他已經在交際能力和領導力方面都可以達到高階水平了。所以他要在我們團隊中做高階程式設計師的工作只是需要提高技術能力而已。

只看技術水平並不夠

對於技術水平高但在領導力和交際能力方面都缺乏經驗的人，不能直說“在我們這裡你達不到高階程式設計師的標準”，這話太刺耳了。但對於他在團隊中能承擔的責任來說，我們可以暫時評訂為中級，等他把另一方面或者兩方面都提高了之後，我們再把他提升為高階。

很多公司只根據技術水平來做判斷，但這樣對於我們這種小型的而且非常依賴合作模式工作的公司來說行不通。其實我非常擔心那些只衡量技術能力的公司是認可“孤獨的天才開發者”這樣的危險想法的，覺得一個人技術水平高，就想當然的認為領導力和交際能力也很好。

在大公司中每個人都只負責一小部分工作，我非常樂於見到他們分享對於“高階程式設計師”的定義，那應該會在技術和非技術的方面都更加全面，讓我們工作得效率更高，尤其是在需要與客戶打交道的團隊裡。

成為高階需要多久？

“高階程式設計師”是不是就意味著“若干年的經驗”？事實上我並沒有看到過哪個人不用五年就可以成為高階程式設計師的。要在很短的時間內就把一些特質發展得非常好來在某一方面達到高階水平其實是非常困難、甚至不可能的，更別說在多個方面全部成為高階了。

而且“五年經驗”並不一定要意味著“五年的軟體開發經驗”。如果一個人已經在領導力和（或）交際能力上滿足了條件，那他只需要提升技術能力，就已經可以發揮高階程式設計師的作用了。

我們招聘的“祕密武器”很大程度上源於我們觀察到的事實：對於具有領導力和交際能力的人來說，要再提升技術能力並不需要很多時間，反之則不然。我見過很多這樣的人，從程式碼集訓營中出來兩三年後就已經成了非常好的高階程式設計師。

更多要討論的

這篇文章留下了非常多未能回答的問題。我們在這三個方面是用什麼具體方法來評估候選人的能力和特質的？在面試前和麵試中該怎麼衡量呢？該如何把這些評估結果與一些具體的東西聯絡起來，比如工資？

這個框架又如何應用於非高階程式設計師？程式設計師們該什麼時候升級？怎麼升級？初級、中級和高階之間的區別是什麼？它們之間差了些什麼？這些詞會不會實際上毫無意義而該被替換掉？

最後，如果真的可以的話，這個框架該如何應用於其他與 Frontside 有著非常大的文化和需求差異的公司？

在下一篇文章中我們會詳細回答這些問題。

告別直覺

定義“高階”是一個仍在進行中的而且出乎人意料困難的過程，但我們還是要做這件事，因為它對我們非常重要。如果不能給“高階程式設計師”下一個清晰的定義，我們就迷失了培養員工的方向，就沒有具體的辦法來衡量要加入我們團隊的人，也沒有辦法讓員工相信我們可以信賴，更沒辦法來改進流程。

這個行業已經應該告別“我一見到這個人我就知道他是個高階程式設計師”這樣下結論的年代了，我們該向著一些我們可以定義和分享的東西努力。讓我們一起把開源的思路帶到我們僱傭和發展員工上吧。

希望我能在下一篇文章中把留下的主要問題都解釋清楚。如果你對文中內容有問題或者不同想法，你可以在 Twitter（@tehviking）上找我，或者更好的方式是，你也把你的想法寫出來，我會在我的文章裡連結過去。