如何尊重一個程式設計師

得知一位久違的老同學來到了灣區，然而我見到他時，這人正處於一生中最痛苦的時期。他對我訴苦說，自己任職的公司在他加入之前和之後，判若兩人。錄取的時候公司對他說，我們對你在實習期間的表現和學術背景非常滿意，你不用面試，甚至不用畢業拿學位，直接就可以加入我們公司成為正式員工。然而短短一年後的今天，這位同學已經完全感覺不到公司對自己技能的尊重。Manager 讓他做一些亂七八糟沒技術含量的事情，還抱怨說他做事太慢，並且在他的 evaluation 上很是寫了一筆。在人格尊嚴和生活安全感的雙重打擊之下，這位同學壓力非常大，週末經常偷偷地加班，仍然無法讓 manager 滿意。

我很瞭解這位同學的能力，在任何一流公司任職，肯定是綽綽有餘了。他的名字我當然保密，然而他所任職的公司，我卻不得不直接指出來——這就是被很多人膜拜得像天堂一樣的地方，Google。這位同學所描述的遭遇，跟我幾年前在 Google 的實習經歷如出一轍。我仍然記得，Google 的隊友在旁邊看著我用 Emacs，用小學老師似的口氣對我說：“按 Ctrl-k！” 我仍然記得，在提交隊友完全無法寫出來的，高難度高水準的程式碼時，被指責和嘲笑不會用 Perforce。我仍然記得，吃飯時同事們對所謂“Google 牛人”眉飛色舞的豔羨……

就算你受到過世界上最好的教育，你能完成世界上沒有第二個人能夠完成的工作，比起 Googler 們心目中的所謂“大牛”，你仍然什麼都不是。在 Google 的每一天，我都感覺自己在上演《皇帝的新裝》。我在給皇帝做一件美輪美奐的衣服，愚蠢或者不稱職的人都看不見這件衣服。皇帝的大臣時不時來視察一下，卻發現無法看見我織的布料…… 我又像是在上演《葉公好龍》，有一位叫葉公的人，聲稱要尋找世界上最頂尖，最有創造力，掌握精髓知識，不循規蹈矩的人才。可當真的見到這種人的時候，他害怕了。他無法理解這種能力，不知道如何尊重它，保護它，使用它。他惱羞成怒，怎麼會有人比我還聰明！他閉上眼默唸，我才是世界上最厲害最聰明最偉大的！他吹毛求疵，用膚淺愚蠢的標準來評判龍的價值……

我的這位同學也算得上本領域頂尖的專家了。如此的踐踏一個專家的價值，用膚淺的標準來評判和對待他們，Google 並不是唯一一個這樣的公司。我之前任職的幾乎所有公司，或多或少都存在類似的問題。有時候這也許不是整個公司的問題，而只是其中一些不懂事的人，然而我很肯定的是，這種現象在 Google，是一種全公司的風氣和行為。Google 的所謂“牛人”（只是所謂）真太多了，所以他們根本不會在乎你。

IT 公司這種不尊重人的現象，不止針對專家級的人物，而且針對所有程式設計師。只不過專家見的東西多了，見慣不驚，所以一般不喜歡用膚淺的東西來凸顯自己。然而正是因為謙虛，他們容易成為被一知半解的人攻擊的物件。由於這種不尊重人現象的普遍性和極強的危害性，我覺得有必要專門講一下。在下文裡，我想指出 IT 業界不尊重人的文化的由來，同時給世界範圍內的 IT 公司提出幾點建議，告訴他們如何真正的尊重一個程式設計師。我希望這些建議對公司的管理層有借鑑意義，也希望它們能給與正在經受同樣痛苦的程式設計師們一些精神上的鼓勵。

我覺得一個懂得尊重程式設計師的公司文化，應該隨時注意以下幾個要點：

承認軟體系統的歷史遺留問題

如果你對電腦科學理解到一定程度，就會發現我們其實仍然生活在計算機的石器時代。相比硬體而言，軟體系統建立在一堆歷史遺留的糟糕設計之上。各種設計蹩腳的作業系統（比如 Unix，Linux），程式語言（比如C++)，資料庫，…… 時常困擾著我們，這就是為什麼你需要那麼多的所謂“經驗”。然而，很多 IT 公司不喜歡承認這一點，他們一向以來的作風是“一切都是使用者的錯！”，“你應該知道這些！” 這就造成了一種“皇帝的新裝現象”：大家都不會用一些設計惡劣的工具，卻都怕別人嘲笑或者懷疑自己的能力，從而沒有人敢指出設計者的失誤。

我這個人呢，就是這種“黑客文化”的一個反例。每當有人因為不會某種工具或者語言來請教我時，我總是很輕鬆的調侃這工具的設計者，然後告訴他，你沒理由知道這些破玩意兒，但其實它就是這麼回事。然後我一陣見血的告訴他這東西怎麼回事，怎麼用，是哪些設計缺陷導致了我們現在的詭異用法…… 我覺得所有的 IT 從業人員對於這些工具，都應該是我這樣的調侃態度。只有這樣，軟體行業才會得到實質性的進步，而不是被一些糟糕的設計所困擾，造成思維枷鎖。

總之，這是一個非常重要的“態度問題”。雖然在現階段，我們有必要知道如何繞過一些設計拙劣的工具，利用它們來完成自己的任務。然而在此同時，我們必須正視和承認這些工具的惡劣本質，而不能怪罪於程式設計師。只有這樣，我們才能有效地尊重程式設計師們的智商。

分清精髓知識和表面知識，不要太拿“經驗”當回事

IT 公司經常有這樣的人，以為精通一些看似複雜的命令列，或者某些難用的程式語言就很了不起似的。這些人沒有發現，自己身邊有些同事其實掌握著精髓的知識，他們完全有能力從自己已有的知識，衍生製造出所有這些工具（而不只是使用它們），甚至設計得更加完善和方便易用。這種能夠設計製造出更好工具的人，往往身負更加重要的任務，所以他們往往會在被現有工具的用法迷惑的時候，非常謙虛的請同事幫助解決，大膽的承認自己的糊塗。

如果你是這個精通工具用法的人，切不可以把同事的謙虛請求當成可以顯擺自己“資歷”的時候。這同事往往真的是在“不恥下問”。他並不是“搞不懂”，而是根本不屑於，也沒有時間去考慮這種低階問題。他的迷惑，往往來源於工具設計者的失誤。他很清楚這一點，然而為了禮貌，他經常不直接批評這工具的設計，而是謙虛的責怪自己。所以同事對你的尊重，完全是為了製造一種友好融洽的氣氛，而並不等於他在膜拜你，承認自己的技術能力不如你。

所以正確的對待方式應該是誠懇的表示對這種迷惑的理解，並且坦率的承認工具設計上的不合理，蹩腳之處。如果你能夠以這種謙和的態度，而不是自以為專家的態度，同事會高興地從你這裡“學到”他需要的，膚淺的死知識，並且記住它，避免下次再為這種無聊事來打擾你。如果你做出一副“天下只有我知道這奇技淫巧”的態度，同事往往會對你，連同這工具一起產生鄙視的情緒。他下次會照樣記不住這東西的用法，然而他卻再也不會來找你幫忙，而是一拖再拖。

不要使用命令語氣，解釋自己的意圖

隨時都要記住，同事和下屬並不是奴隸，不是 code monkey，他們不一定要為你工作！他們是通情達理的人，然而卻不會因為拿了工資就簡單地服從你的低階命令。像我在 Google 的隊友的做法，就是一個很好的反面教材。其實這位 Googler 只是想告訴我“刪掉這行文字，然後改成這樣……”，然而她卻沒有直接表明這種“高階意圖”，而是使用非常低階的指令：“按 Ctrl-k！……” 而且語氣像是在對一個不懂事的小學生說話。

有哪個 Emacs 使用者不知道 Ctrl-k 是刪掉一行字呢，況且你現在面對的其實是一個資深 Emacs 使用者，世界級的 Lisp 程式設計師。我想大家都看出來這裡的問題了吧。這樣的低階命令不但邏輯不清楚，而且讓人反感。你當我是什麼啊？code monkey？如果這位 Googler 表明自己的高階意圖，就會很容易在心理上和邏輯上讓人接受，比如她可以說：“配置檔案的這行應該刪掉，改成……”

在專案管理的其他時候也可以使用類似的技巧。在讓人做某一件事之前，先要解釋為什麼要做這件事以及它的重要性，要讓人理解。只有這樣，才能尊重程式設計師的智商，因為他們是人，並不是只會服從你指揮的 code monkey。

不要期望新人向自己學習

很多 IT 公司喜歡把新人當初學者，期望他們向自己“學習”。比如，Google 把所有新員工叫做“Noogler”（Newbie Googler 的意思），甚至給他們發一種特殊的螺旋槳帽子，其寓意在於告訴他們，小朋友要謙虛，要向“偉大的 Google”學習，將來才可以飛黃騰達。

這其實是非常錯誤的作法，它無視新員工已有的背景知識，讓他們屈服於“偉大的 Google”的權威之下，成為一顆不起眼的螺絲釘。其實 Google 裡面真的有很多值得學習的東西嗎？學校的教育真的一文不值嗎？並非如此。我可以坦然的說，我從自己的教授身上學會了最精髓的知識。我並沒有從 Google 學到任何可以超越那些精髓的技能，反倒送給 Google 很多世界上最先進的，任何 Googler 都想不到的技術。很多其它 PhD 學生鄙視 Google，就是因為 Google 不但自己技術很多一團糟，反倒把自己包裝成最先進的，超越其它公司和所有學校的，並且囂張的期望別人向他們“學習”。

只有瞭解，尊重和發揮新人從外界帶來的特殊技能，施展他們特有的長處，而不是一味期望他們向自己“學習”，才能保持這些銳利的武器的稜角，讓公司立於不敗之地。

程式設計師的工作量不可用時間衡量

很多 IT 公司管理層不懂得如何估算程式設計師的工作量。如果你能力很強，在很短的時間內把最困難的問題解決了，接下來他們不會讓你閒著，而會讓你做另外一些很低階的活。這是很不合理的作法。打個比方，能力強的員工就像一輛 F1 賽車，馬力和速度是其他人的幾十倍。當然，普通人需要很長時間才能解決，甚至根本沒法解決的問題，到他手裡很快就化解掉了。這就像一輛 F1 賽車，眨眼工夫就跑完了別人需要很久的路程。如果你用時間來衡量工作量，那麼這輛 F1 賽車跑完全程只需要很短時間，所以你算出來的工作量就比普通車子小很多。你能因此說 F1 賽車工作不夠努力，要他快馬再加鞭嗎？這顯然是不對的。

物理定律是這樣：能量 = 功率 x 時間。工作量也應該是同樣的計算方法。英明的，真正理解程式設計師的公司，就不會指望高水平的程式設計師不停地工作。高水平程式設計師由於經常能夠另闢蹊徑，一個就可以抵好幾個甚至幾十個普通程式設計師。他們處理的問題比常人的困難很多，費腦力多很多，當然他們需要更好的休息，保養，娛樂，……

當然這並不是說初級的程式設計師就應該過量工作。程式設計是一項艱苦的腦力活動，超時超量的工作再加上壓力，只會帶來效率的低下，質量的降低。

不要讓其他人修補自己的 BUG

這個我已經在一篇專門的文章裡討論過。讓一個程式設計師修補另外一個程式設計師的 BUG，不但是效率低下，而且是不尊重程式設計師個人價值的作法，應該儘量避免。如果有人離開公司，必須要有人修補他遺留下來的 BUG，那麼說話應該特別特別的小心。你要特別的指出需要他幫忙的特殊原因，強調這件事本來不是他的問題，本來是不應該他來做的，但是有人走了，沒有辦法，並且誠懇的為此類事情的發生表示歉意。

只有這樣，程式設計師才會心甘情願的在這種罕見的特殊關頭，修補另外一個人的 BUG。