我很瞭解這位同學的能力，在任何一流公司任職，肯定是綽綽有餘了。他的名字我當然保密，然而他所任職的公司，我卻不得不直接指出來——這就是被很多人膜拜得像天堂一樣的地方，Google。這位同學所描述的遭遇，跟我幾年前在Google的實習經歷如出一轍。我仍然記得，Google的隊友在旁邊看著我用Emacs，用小學老師似的口氣對我說：“按Ctrl-k！” 我仍然記得，在提交隊友完全無法寫出來的，高難度高水準的程式碼時，被指責和嘲笑不會用Perforce。我仍然記得，吃飯時同事們對所謂“Google牛人”眉飛色舞的豔羨……
就算你受到過世界上最好的教育，你能完成世界上沒有第二個人能夠完成的工作，比起Googler們心目中的所謂“大牛”，你仍然什麼都不是。在Google的每一天，我都感覺自己在上演《皇帝的新裝》。我在給皇帝做一件美輪美奐的衣服，愚蠢或者不稱職的人都看不見這件衣服。皇帝的大臣時不時來視察一下，卻發現無法看見我織的布料…… 我又像是在上演《葉公好龍》，有一位叫葉公的人，聲稱要尋找世界上最頂尖，最有創造力，掌握精髓知識，不循規蹈矩的人才。可當真的見到這種人的時候，他害怕了。他無法理解這種能力，不知道如何尊重它，保護它，使用它。他惱羞成怒，怎麼會有人比我還聰明！他閉上眼默唸，我才是世界上最厲害最聰明最偉大的！他吹毛求疵，用膚淺愚蠢的標準來評判龍的價值……
我的這位同學也算得上本領域頂尖的專家了。如此的踐踏一個專家的價值，用膚淺的標準來評判和對待他們，Google並不是唯一一個這樣的公司。我之前任職的幾乎所有公司，或多或少都存在類似的問題。有時候這也許不是整個公司的問題，而只是其中一些不懂事的人，然而我很肯定的是，這種現象在Google，是一種全公司的風氣和行為。Google的所謂“牛人”（只是所謂）真太多了，所以他們根本不會在乎你。
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。
來自：PHP100
評論(1)