學會怎樣尊重一個程式設計師

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。

免費領取LAMP兄弟連原創PHP影片教學光盤，請填/寫/寫真/寫真.情諮詢官網客服： http://www.lampbrother.netPHPCMS二次開發

http://yun.itx.cn/online/phpcms/index.php?u=5http://yun.itxdl.cn/online/phpcms/index.php?u=5。

              http://yun.itxdl.cn/online/weixin/index.php?u=5行動網路伺服器端開發php?u=5

Javascript課程      http://yun.itxdl.cn/online/js/index.php?u=5🎠   http:/ /yun.itxdl.cn/online/cto/index.php?u=5

以上就介紹了學會怎樣尊重一個程式設計師，包括了方面的內容，希望對PHP教程有興趣的朋友有幫助。