我很瞭解這位同學的能力，在任何一流公司任職，肯定是綽綽有餘了。他的名字我當然保密，然而他所任職的公司因為太過囂張，我不得不直接指出來——這 就是被很多人嚮往得像天堂一樣的地方，Google。這位同學所描述的遭遇，跟我幾年前在Google的實習經歷如出一轍。我仍然記得，Google的隊 友在旁邊看著我用Emacs，用小學老師似的口氣對我說：“按Ctrl-k！” 我仍然記得，在提交隊友完全無法寫出來的高難度程式碼時，被指責和嘲笑不會用Perforce。我仍然記得，吃飯時同事們對所謂“Google牛人”眉飛色 舞的豔羨。我仍然記得，最後我一個人做出整個團隊做夢都做不出來的專案的時候，有人發出沉悶的咆哮：“快——寫——測——試！” ……
我的這位同學也算得上本領域頂尖的專家了。如此的踐踏一個專家的價值，用膚淺的標準來評判和對待他們，Google並不是唯一一個這樣的公司。我之 前任職的好幾個公司，或多或少都存在類似的問題。很多時候也不一定是公司管理層無端施加壓力，而是程式設計師之間互斗的厲害，互相評判，傷害自尊。從最近Linus Torvalds在演講現場公然對觀眾無理，你可以看出這種只關心技術，不尊重人的思潮，在程式設計師的社群裡是非常普及的。
後來我發現，並不是程式設計師故意想要藐視對方或者互相攻擊，而是他們真的不明白什麼叫做“尊重”，他們不知道如何說話才可以不傷害另一個程式設計師，所以 有時不小心就讓人怒火中燒。所以說，尊重他人其實是一個“技術問題”，而不是有心就可以做到的。因為這個原因，我想在下文裡從心理和技術角度出發，指出 IT業界不尊重人現象的起源，同時提出幾點建議，告訴人們如何真正的尊重一個程式設計師。我希望這些建議對公司的管理層有借鑑意義，也希望它們能給與正在經受 同樣痛苦的程式設計師們一些精神上的鼓勵。
我覺得為了建設一個程式設計師之間互相尊重的公司文化，應該注意以下幾個要點。
認識和承認計算機系統裡的歷史遺留糟粕
很多不尊重人現象的起源，都是因為某些人偏執的相信某種技術就是世界上最好的，每個人都必須知道，否則他就不是一個合格的程式設計師。這種現象在 Unix（Linux）的世界尤為普遍。Unix系統的鼓吹者們（我曾經是其中之一）喜歡到處佈道，告訴你其它系統的設計有多蠢，你應該遵從Unix的 “哲學”。他們彷彿認為Unix就是世界終極的作業系統，然而事實卻是，Unix是一個設計非常糟糕的系統。它似乎故意被設計為難學難用，容易犯錯，卻美 其名曰“強大”，“靈活”。眼界開闊一點的程式設計師都知道，Unix的設計者其實基本不懂設計，他們並不是世界上最好的程式設計師，卻有一點做得很成功，那就是 他們很會製造宗教，煽動人們的盲從心理。Unix設計者把自己的設計失誤推在使用者身上，讓使用者覺得學不會或者搞錯了都是自己的錯。
如果你對電腦科學理解到一定程度，就會發現我們其實仍然生活在計算機的石器時代。特別是軟體系統，建立在一堆歷史遺留的糟糕設計之上。各種蹩腳腦 殘的作業系統（比如Unix，Linux），程式語言（比如C++，JavaScript，PHP，Go)，資料庫，編輯器，版本控制工具，…… 時常困擾著我們，這就是為什麼你需要那麼多的所謂“經驗”和“知識”。然而，很多IT公司不喜歡承認這一點，他們一向以來的作風是“一切都是程式設計師的 錯！”，“作為程式設計師，你應該知道這些！” 這就造成了一種“皇帝的新裝現象”——大家都不喜歡用一些設計惡劣的工具，卻都怕別人嘲笑或者懷疑自己的能力，所以總是喜歡顯示自己“會用”，“能學”， 而沒有人敢說它難用，敢指出設計者的失誤。
我這個人呢，就是這種“黑客文化” 的一個反例。我所受到的多元化教育，讓我從這些偏激盲從，教條主義的心理裡面跳了出來。每當有人因為不會某種工具或者語言來請教我時，我總是很輕鬆的調侃 這工具的設計者，然後告訴他，你沒理由知道這些破玩意兒，但其實它就是這麼回事。然後我一針見血的告訴他這東西怎麼回事，怎麼用，是哪些設計缺陷導致了我 們現在的詭異用法…… 我覺得所有的IT從業人員對於這些工具，都應該是這樣的調侃態度。只有這樣，軟體行業才會得到實質性的進步，而不是被一些自虐的設計所困擾，造成思維枷 鎖。
總之，這是一個非常重要的“態度問題”。雖然在現階段，我們有必要知道如何繞過一些蹩腳的工具，利用它們來完成自己的任務。然而在此同時，我們必須 正視和承認這些工具的惡劣本質，而不能拿它們當教條，把什麼事都怪罪於程式設計師。只有分清工具設計者的失誤和程式設計師自己的失誤，不把工具的設計失誤怪罪於程 序員，我們才能有效地尊重程式設計師們的智商，鼓勵他們做出簡單，優雅，完善的產品。
分清精髓知識和表面知識，不要太拿經驗當回事
在任何領域，都只有少數知識是精髓的，另外大部分都是表面的，膚淺的，是從精髓知識衍生出來的。精髓知識和表面知識都是有用的，然而它們的分量和重 要性卻是不一樣的。所以必須區分精髓知識和表面知識，不能混為一談，對待它們的態度應該是不一樣的。由於表面知識基本是死的，而且很容易從精髓知識推導衍 生出來。我們不應該因為自己知道很多表面知識，就自以為比掌握了精髓知識的人還要強。不應該因為別人不知道某些表面知識，就以為自己高人一等。
IT公司經常有這樣的人，以為精通一些看似複雜的命令列，或者某些難用的程式語言就很了不起似的。他們如果聽說你不知道某個命令的用法，那簡直就像 法國人不知道拿破崙，美國人不知道華盛頓一樣。這些人沒有發現，自己身邊有些同事其實掌握著精髓的知識，他們完全有能力從自己已有的知識，衍生製造出所有 這些工具，而不只是使用它們，甚至設計得更加完善和方便易用。這種能夠設計製造出更好工具的人，往往身負更加重要的任務，所以他們往往會在被現有工具的用 法迷惑的時候，非常謙虛的請同事幫助解決，大膽的承認自己的糊塗。
如果你是這個精通工具用法的人，切不可以把同事的謙虛請求當成可以顯擺自己“資歷”的時候。這同事往往真的是在“不恥下問”。他並不是搞不懂，而是 根本不屑於，也沒有時間去考慮這種低階問題。他的迷惑，往往來源於工具設計者的失誤。他很清楚這一點，他也知道自己的技術水平其實是高於這工具的設計者 的。然而為了禮貌，他經常不直接批評這工具的設計，而是謙虛的責怪自己。所以同事向你“虛心請教”，完全是為了製造一種友好融洽的氣氛，這樣可以節省下時 間來幹真正重要的事情。這種虛心並不等於他在膜拜你，承認自己的技術能力不如你。
所以正確的對待方式應該是誠懇的表示對這種迷惑的理解，並且坦率的承認工具設計上的不合理，蹩腳之處。如果你能夠以這種謙和的態度，而不是自以為專 家的態度，同事會高興地從你這裡“學到”他需要的，膚淺的死知識，並且記住它，避免下次再為這種無聊事來打擾你。如果你做出一副“天下只有我知道這奇技淫 巧”的態度，同事往往會對你，連同這工具一起產生鄙視的情緒。他下次會照樣記不住這東西的用法，然而他卻再也不會來找你幫忙，而是一拖再拖。
不要自以為聰明，不要評判別人的智商和能力
在IT公司裡，總是有很多人覺得自己聰明，想顯示自己比別人聰明。這種人似乎隨時都在評判（judge）別人，你說的任何話，不管認真的還是開玩笑的，都會被他們拿去作為評估你智商和能力的依據。
有時候你寫了一些程式碼，自己知道時間不夠，可是當時有更重要的事情要做，所以打算以後再改進。如果你提交程式碼時被這種人看到了，他們就會堅定地認為 你一輩子只能寫出那樣的程式碼。這就是所謂“wishful thinking”，人只能看到他希望看到的東西。這種人隨時都在希望自己比別人聰明，所以他們隨時都在監聽別人顯得不如他聰明的時候，而對別人比他高明 的時候視而不見。他們只能看到別人疏忽的時候，因為那是可以證明他們高人一等的有利證據。
當然，誰會喜歡這樣的人呢，可是他們在IT公司裡相當的普遍。你不敢跟他們說話，特別是不敢開玩笑，因為他們會把你稀裡糊塗的玩笑話全部作為你智商 低下或者經驗不足的證據。你不敢問他們問題，因為他們會認為你問問題，說明你不懂！我發現具有這種心理的人，一般潛意識裡都存在著自卑。他們有某些方面 （包括智力在內）不如別人，所以總是找機會顯得高人一等。我還沒有想出可以糾正這種心理問題的有效方法，但如我上節所說，意識到整個行業，包括你仰慕的鼻 祖們，其實都不懂很多東西，都是混飯吃的，是一個有效的放鬆這種心理的手段。
有時候我喜歡自嘲，對人說：“我們這行業的祖先做了這麼多BUG來讓我們修補。現在你做了一坨屎，我也做了一坨屎，我的屎貌似比你的屎香一點。”這 樣一來，不但顯示出心理的平等和尊重，而且避免了因為謙虛而讓對方產生高人一等的情緒。說真的，做這行根本不需要很高的智力，所以最好是完全放棄對人智力 的判斷。你不比任何人更聰明，也不比他們笨。
解釋高階意圖，不要使用低階命令
隨時都要記住，同事和下屬是跟你智力相當的人。他們是通情達理的人，然而卻不會簡單地服從你的低階命令。像我在Google的隊友的做法，就是一個 很好的反面教材。其實這位Googler只是想告訴我：“刪掉這行文字，然後改成這樣……” 就是如此一個簡單的事情，然而她卻故弄玄虛，不直接告訴我這個“高階意圖”，而是使用非常低階的指令：“按Ctrl-k！……” 語氣像是在對一個不懂事的小學生說話，好像自己懂很多，別人什麼都不知道似的。
有哪個Emacs使用者不知道Ctrl-k是刪掉一行字呢，況且你現在面對的其實是一個資深Emacs使用者。我想大家都看出來這裡的問題了吧。這樣的 低階命令不但邏輯不清楚，而且是對另一個人的智力的嚴重侮辱。你當我是什麼啊？猴子？如果這位Googler表明自己的高階意圖，就會很容易在心理上和邏 輯上讓人接受，比如她可以說：“配置檔案的這行應該刪掉，改成……”
在專案管理的時候也需要注意。在讓人做某一件事之前，應該先解釋為什麼要做這件事，以及它的重要性。這樣才能讓人理解，才能尊重程式設計師的智商。
不要期望新人向自己學習
很多IT公司喜歡把新人當初學者，期望他們“從新的起跑線出發”，向自己“學習”。比如，Google把新員工叫做“Noogler” （Newbie Googler的意思），甚至給他們發一種特殊的螺旋槳帽子，其寓意在於告訴他們，小屁孩要謙虛，要向偉大的Google學習，將來才可以飛黃騰達。
一個真正尊重人才的公司會去了解，尊重和發揮新人從外界帶來的特殊技能，施展他們特有的長處，而不是一味期望他們向自己“學習”。只有這樣，我們才 能保持這些銳利武器的稜角，在激烈的競爭中讓自己立於不敗之地。如果你一味的讓新人“學習”，而無視他們特有的長處，最後就不免淪為平庸。
不要以老師自居，分清“學習”和“瞭解”
如上文所說，IT行業的很多所謂“知識”，只不過是一些奇技淫巧，用以繞過前人設計上的失誤。所以遇到別人不知道一些東西的時候，請不要以為你“教 會”了別人什麼東西，不要以為自己可以當老師了。以老師自居，使用一些像“跟我學”一類的語言，其實是一種居高臨下，不尊重人的行為。
人們很喜歡在獲得了資訊的時候用“學習”這個詞，然而我覺得這個詞被濫用了。我們應該分清兩種情況：“學習”和“瞭解”。前者指你通過別人的指點和 自己的理解，獲得了精髓的，不能輕易製造出來的知識。後者只是指你“瞭解”了原來不知道的一些事情。舉個例子，如果有人把一件物品放在了某個你不知道的地 方，你找不到，問他，然後他告訴你了。這種資訊的獲取，顯然不叫“學習”，這種資訊也不叫做“知識”。
然而，IT行業很多時候所謂的“學習”，就是類似這種情況。比如，有人寫了一些程式碼，設計了一些框架模組。有人不知道怎麼用，然後有人告訴他了。很 多人把這種情況稱為“學習”，這其實是對人的不尊重。這跟有人告訴你他把東西放在哪裡了，是同樣性質的。這樣的程式碼和設計，我也可以做，甚至做得更好，憑 什麼你說我在向你學習呢？我只是瞭解了一下而已。
所謂學習，必須是更加高階的知識和技能，必須有一種“有收穫”，“有提高”的感覺。簡單的資訊獲取不能叫做“學習”，只能叫做“瞭解”。分清“瞭解”和“學習”，不以老師自居，是尊重人的一個重要表現。
明確自己的要求，不要使用指責的語氣
有些人很怪異，他根本沒告訴過你他想要什麼，有什麼特別的要求，可他潛意識裡假設已經告訴你了。到了後來，他發現你的作法不符合要求，於是嚴厲指責 你沒有按照他“心目中的要求”辦事。這種現象不止限於程式設計師，而且包括日常生活中的普通人。舉個例子，我媽就是這種人的典型，所以我以前在家生活經常很辛 苦。她心目中有一套“正確”的做事方式，如果你沒猜出來就會捱罵。你為了避免捱罵，乾脆什麼事都不要做，然後她又會說你懶，所以你就左右不是人 :)
IT公司裡面也有挺多這樣的人，他們假設有些資訊他已經告訴你了，而其實根本沒告訴你。到了後來，他們開始指責你沒有按照要求做事。有些極其奇葩的 公司，裡面的程式設計師不但喜歡以老師自居，而且他們“傳授”你“知識”的主要方式是指責。他們事先不告訴你任何規則，然後只在你違反的時候來責備你。我曾經 在這樣一個公司待過，名字就不提了。
現在舉一個具體的場景例子：
A: 你push到master了？
B: 是啊？怎麼了？
A: 不準push到master！只能用pull request！
B: 可是你們之前沒告訴過我啊……
A: 現在你知道了？！
注意到了嗎？這不是一個技術問題，而是一個禮節（etiquette）問題。你沒有事先告訴別人一些規則，就不該用怪罪的語氣來對人說話，況且你的 規則還不一定總是對的。所以我現在提醒各位IT公司，在技術上的某些特殊要求必須事先提出來，確保程式設計師知道並且理解。如果沒有事先提出，就不要怪別人沒 按要求做，因為這是非常傷害人自尊的作法。其實，在任何時候都不應該使用指責的語氣，它不但對解決問題沒有任何正面作用，而且會惡化人際關係，最終導致更 加嚴重的後果。
程式設計師的工作量不可用時間衡量
很多IT公司管理層不懂得如何估算程式設計師的工作量，所以用他們坐在自己位置上工作的時間來估算。如果你能力很強，在很短的時間內把最困難的問題解決 了，接下來他們不會讓你閒著，而會讓你做另外一些很低階的活。這是很不合理的作法。打個比方，能力強的員工就像一輛F1賽車，馬力和速度是其他人的幾十 倍。當然，普通人需要很長時間才能解決，甚至根本沒法解決的問題，到他手裡很快就化解掉了。這就像一輛F1賽車，眨眼工夫就跑完了別人需要很久的路程。如 果你用時間來衡量工作量，那麼這輛賽車跑完全程只需要很短時間，所以你算出來的工作量就比普通車子小很多。你能因此說賽車工作不夠努力，要他快馬再加鞭 嗎？這顯然是不對的。
物理定律是這樣：能量 = 功率 x 時間。工作量也應該是同樣的計算方法。英明的，真正理解程式設計師的公司，就不會指望高水平的程式設計師不停地工作。高水平程式設計師由於經常能夠另闢蹊徑，一個就可 以抵好幾個甚至幾十個普通程式設計師。他們處理的問題比常人的困難很多，費腦力多很多，當然他們需要更好的休息，保養，娛樂，…… 如果你讓高水平的程式設計師太忙了，一刻都不停著，有趣有挑戰性的事情做完了就讓他們做一些低階無聊的事情，他們悟出這個道理之後，就會故意放慢速度，有時候 明明很快做完了也會說沒做完。與其這樣，不如只期望他們工作短一點的時間，把事情做完就可以。
當然這並不是說初級的程式設計師就應該過量工作。程式設計是一項艱苦的腦力活動，超時超量的工作再加上壓力，只會帶來效率的低下，質量的降低。
不要讓其他人修補自己的BUG
這個我已經在一篇專門的文章裡討論過。讓一個程式設計師修補另外一個程式設計師的BUG，不但是效率低下，而且是不尊重程式設計師個人價值的作法，應該儘量避免。
在軟體行業，經常看到有的公司管理讓一個人修補另一個人程式碼裡的BUG。有時候有人寫了一段程式碼，扔出來不管了，然後公司管理讓其他工程師來修復它。我想告訴你們，這種方法會很失敗。
首先，讓一個人修復另一個人的BUG，是不尊重工程師個人技術的表現。久而久之會降低工程師的工作積極性，以至於失去有價值的員工。程式碼是人用心寫 出來的作品，就像藝術家的作品一樣，它的質量牽掛著一個人的人格和尊嚴。如果一個人A寫了程式碼，自己都不想修復裡面的BUG，那說明A自己都認為他自己的 程式碼是垃圾，不可救藥。如果讓另一個人B來修復A程式碼裡的BUG，就相當於是讓B來收拾其他人丟下的垃圾。可想而知，B在公司的眼裡是什麼樣的地位，受到 什麼樣的尊重。
其次，讓一個人修復另一個人的BUG，是效率非常低下的作法。每個人都有自己寫程式碼的風格和技巧，程式碼裡面包含了一個人的思維方式。人很難不經解釋 理解別人的思想，所以不管這兩人的程式設計技術高下，都會比較難理解。不能理解別人的程式碼，不能說明這人程式設計技術的任何方面。所以讓一個人修補另一個人的 BUG，無論這人技術多麼高明，都會導致效率低下。有時候技術越是高的人，修補別人的BUG效率越是低，因為這人根本就寫不出來如此糟糕的程式碼，所以他無 法理解，覺得還不如推翻重寫一遍。
當我在大學裡做程式設計課程助教的時候，我發現如果學生的程式碼出了問題，你基本是沒法簡單的幫他們修復的。我的水平顯然比學生的高出許多，然而我卻 經常根本看不懂，也不想看他們的程式碼，更不要說修復裡面的BUG。就像上面提到的，有些人自己根本不知道自己在寫什麼，做出一堆垃圾來。看這樣的程式碼跟吃 屎的感覺差不多。對於這樣的程式碼，你只能跟他們說這是不正確的。至於為什麼不正確，你只能讓他們自己去改，或者建議他們推翻重寫。也許你能指出大致的方向 和思路，然而深入到具體的細節卻是不可能的，而且不應該是你的職責。這就是我的教授告訴我的做法：如果程式碼不能執行，直接打一個叉，不用解釋，不用推敲， 等他們自己把程式改好，或者實在沒辦法，來office hours找你，向你解釋他們的思想。
如果你明白我在說什麼，從今天起就對自己的程式碼負起責任來，不要再讓其它人修補自己的BUG，不要再修補其他人的BUG。如果有人離開公司，必須要 有人修補他遺留下來的BUG，那麼說話應該特別特別的小心。你必須指出需要他幫忙的特殊原因，強調這件事本來不是他的錯，本來是不應該他來做的，但是有人 走了，沒有辦法，並且誠懇的為此類事情的發生表示歉意。只有這樣，程式設計師才會心甘情願的在這種特殊關頭，修補另外一個人的BUG。
不要嚷著要別人寫測試
在很多程式設計師的腦子裡，所謂的“流程”和“測試”，比真正解決問題的程式碼還重要。他們跟你說起這些，那真的叫正兒八經，義正言辭啊！所以有時候你很 迷惑，這些人除了遵守這些按部就班的規矩，還知道些什麼。大概沒有能力的人都喜歡追究各種規矩吧，這樣可以顯得自己“沒有功勞有苦勞”。這些人自己寫的代 碼很平庸，不知道如何簡單有效地解決困難的問題，卻喜歡在別人提交程式碼讓他review的時候叫喊：“測試很重要！覆蓋很重要！你要再加一些測試才能通過 我的review！”
本來code review是讓他們幫忙發現可能存在的問題，有些人卻彷彿把它作為了評判（judge）其他人能力，經驗，甚至智商的機會。他們根本不明白別人程式碼的實 質價值，就知道以一些表面現象來判斷。我在Google實習，最後提交了質量和難度都非常高的程式碼，然而一些完全沒能力寫出這樣程式碼的人，不但沒表示出最 基本的肯定，反而發出沉悶的咆哮：“快——寫——測——試！” 你覺得我會高興嗎？
我並不否認測試的用處，然而很多人提起這些事情時候，語氣和態度是非常不尊重，讓人反感的。這些人不但沒有為解決問題作出任何實質貢獻，當有人提交 解決方案的時候，他們沒有表達對真正做出貢獻的人的尊重和肯定，反而指責別人沒寫測試。好像比他高明的人解決了問題，他反倒才是那個有發言權的，可以評判 你的程式碼質量似的：“我管你程式碼寫得多好，我完全沒能力寫出來，但你沒寫測試就是不夠專業。你懂不懂測試的重要性啊，還做程式設計師！”
人際交往的問題經常不在於你說了什麼，而在於你是怎麼說的。所以我的意思並不是說你不該建議寫測試，然而建議就該有建議的語氣和態度。因為你沒有做 實際的工作，所以一些禮貌用語，比如“請”，“可不可以”……是必須的。經常有人說話不注意語氣和態度，讓人反感，卻以自己是工程師，不善於跟人說話為借 口。永遠要記住，你沒有做事，說話就應該委婉，切不可使用光禿禿的祈使句，說得好像這事別人非做不可，不做就是不懂規矩一樣。
禮貌的語言，跟人的職業完全沒有關係。身為工程師，完全不能作為說話不禮貌的藉口。
關於Git的禮節
Git是現在最流行的程式碼版本控制工具。用外行話說，Git就是一個程式碼的“倉庫”或者“保管”，這樣很多人修改了程式碼之後，可以知道是誰改了哪一 塊。其實不管什麼工具，不管是編輯器，程式語言，還是版本控制工具，比起程式設計師的核心思想來，都是次要的東西，都是起輔助作用的。可是Git這工具似乎特 別惹人惱火。
Git並不像很多人吹噓的那麼好用，其中有明顯的蹩腳設計。跟Unix的傳統一脈相承，Git沒有一個良好的包裝，設計者把自己的內部實現細節無情 地洩露給了使用者，讓使用者需要琢磨者設計者內部到底怎麼實現的，否則很多時候不知道該怎麼辦。使用者被迫需要記住挺多稀奇古怪的命令，而且命令列的設計也不怎 麼合理，有時候你需要加-f之類的引數，各個引數的位置可能不一致，而且加了還不一定能起到你期望的效果。各種奇怪的現象，比如"head detached"，都強迫使用者去了解它內部是怎麼設計的。隨著Git版本的更新，新的功能和命令不斷地增加，後來你終於看到命令列裡出現了 foreach，才發現它的命令列就快變成一個（劣質的）程式語言。如果你瞭解ydiff的設計思想，就會發現Git之類基於文字的版本控制工具，其實屬於古代的東西。然而很多人把Git奉為神聖，就因為它是Linus Torvalds設計的。
Git最讓人惱火的地方並不是它用起來麻煩，而是它的“資深使用者”們居高臨下的態度給你造成的心理陰影。好些人因為自己“精通Git”就以為高人一 等，擺出一副專家的態度。隨著使用者的增加，Git最初的設計越來越被發現不夠用，所以一些約定俗成的規則似乎越來越多，可以寫成一本書！跟Unix的傳統 一脈相承，Git給你很多可以把自己套牢的“機制”，到時候出了問題就怪你自己不知道。所以你就經常聽有人煞有介事的說：“並不是Git允許你這麼做，你 就可以這麼做的！Unix的哲學是不阻止傻人做傻事……” 如果你提交程式碼時不知道Git使用者一些約定俗成的規則，就會有人嚷嚷：“rebase了再提交！” “不要push到master！” “不要merge！” “squash commits！” 如果你不會用git submodule之類的東西，有人可能還會鄙視你，說：“你應該知道這些！”
打個比方，這樣的嚷嚷給人的感覺是，你得了奧運會金牌之後，把練習用的器材還回到器材保管科，結果管理員對你大吼：“這個放這邊！那個放那邊！懂不 懂規矩啊你？” 看出來問題了嗎？程式設計師提交了有高價值的程式碼（奧運金牌），結果被一些自認為Git用的很熟的人（器材保管員）厲聲呵斥。
一個尊重程式設計師的公司文化，就應該把程式設計師作為運動健將，把程式設計師的程式碼放在尊貴的地位。其它的工具，都應該像器材保管科一樣。我們尊重這些器材保 管員，然而如果運動員們不懂你制定的器材擺放規矩，也應該表示出尊重和理解，說話應該和氣有禮貌，不應該騎到他們頭上。所以，對於Git的一些命令和用 法，我建議大家向新手介紹時，這樣開場：“你本來不該知道這些的，可是現在我們沒有更好的工具，所以得這樣弄一下……”
來自：開源中國
相關閱讀
評論(1)