說說技術(shù)人員的耐心和包容心
情緒化不是一個成熟的職場人士所應有的處事方式，但在我們技術(shù)人員中間卻可能更容易的出現(xiàn)。
有一個技術(shù)人員都知道的很老的段子。如果我們想將一個技術(shù)論壇搞火起來，那么我們只需要發(fā)一篇帖子——php 是世界上最好的語言。雖然是很老的段子，但現(xiàn)在還常常被人提起，很有意思。
不僅僅是在論壇中，在我們?nèi)粘５膱F隊合作中，其實也常常有這樣的事情。回憶一下，在 Code Review 中，是不是常常有某一行代碼引起了大家的廣泛討論，把整個會議給“搞火”了？大家可能就一個問題討論很久，爭執(zhí)不下。
對于這樣的討論，如果大家能心平氣和，互相理解，可能能較快的達成一致，但事實上常常會出現(xiàn)這樣的情況，雙方爭論很久爭執(zhí)不下，后來可能有人說，“這你都不知道啊”，或者“這我理解不了，你這里明顯有問題”，或者“你說的都好，我用我的方式”，或者“你這里就明顯是在#define true=false”等等。
在這樣的討論中，我們比較容易情緒化（可能沒有情緒化這么嚴重，這里姑且先用這個詞），演變到最后，原本心平氣和的討論就變成了針對某個個人的互懟，或者直接拒絕交流。一旦情況變成這樣，那么不僅討論效率會大大下降，還會使得彼此心生芥蒂，影響后面的高效合作。
情緒化不是一個成熟的職場人士所應有的處事方式，但在我們技術(shù)人員中間卻可能更容易的出現(xiàn)。因為大家邏輯能力強，，思維也都很敏捷，追求高效率，相對更缺乏耐心。如果大家還能回憶得起來，《社交網(wǎng)絡(luò)》中的扎克伯格的形象可能是一個典型的高效技術(shù)人員的形象，說話滔滔不絕，做事雷厲風行。我發(fā)現(xiàn)身邊的技術(shù)人員多多少少都具有點這樣的特質(zhì)。我自己反思下來，也常常發(fā)現(xiàn)自己有不夠耐心的時候。比如某次在和他人交流的時候，對方話還沒說完，我就著急開始講話，然后對方不得已也跟著著急的說“你先聽我說完嘛”。
正因為如此，我們技術(shù)人員可能更需要有一顆耐心和包容心。在沒有寫代碼，而是跟其他人討論交流時，我們有沒有即時的切換狀態(tài)，更耐心的對待他人的問題？我們在看別人的代碼的時候，當發(fā)現(xiàn)有一些不是自己所推崇的模式的時候，有沒有仔細想一下別人為什么要這么做？我們在遺留代碼上面工作的時候，是不是一邊工作一邊吐槽代碼寫得太爛，而沒有考慮到當時可能有各種各樣的原因？我們是不是只一味的自己講話，而沒有仔細傾聽對方的話？
一個例子
印象較深刻的有這樣一個例子，我們的代碼里面有這樣的一段邏輯：
- class Something {
- private Map<String, Object> attributes;
- public <T> T getAttribute (String name) {
- return (T) attributes.get(name);
- }
- ...
- }
當我們在 review 代碼的時候，有人一看到上面這行代碼，還沒等人解釋為什么要這么做就直接說，“這個地方明顯有問題啊，更好的方式是返回一個Option，讓調(diào)用方去處理異常”。當作者開始要解釋的時候，他又表現(xiàn)得聽不進去，始終堅持自己是對的。最后由于這個小問題，可能要討論十分鐘。
這個問題的原因是什么呢？原來是由于Something里面的屬性其實是調(diào)用方自己定義的，由于業(yè)務(wù)的要求，調(diào)用方可以定義各種類型的屬性，而當調(diào)用方想要獲取某一個屬性的時候，就通過getAttribute獲取。作者的設(shè)計意圖是提供一個便捷的類型轉(zhuǎn)換功能，封裝這類類型強制轉(zhuǎn)換的代碼，避免這類不好的代碼泄漏到每一個調(diào)用此方法的地方，而假設(shè)調(diào)用方確定的知道所查詢的屬性是什么類型（屬性是調(diào)用方自己定義的）。如果這里的類型轉(zhuǎn)換出錯，那么會拋出一個運行時異常，這是寫代碼時就必須要處理的 bug。
這里的分析合情合理，在我看來是完全可以接受的。試想，如果我們返回一個Option，每一個調(diào)用的地方都需要處理類型轉(zhuǎn)換失敗的情況，而調(diào)用方要如何處理呢？似乎也只能將其拋給更上層。其實這里作為調(diào)用方可能會很奇怪，為啥我明明知道不會拋出異常，還需要顯示的處理異常呢？而且由于這樣的調(diào)用方可能很多，每個地方都需要處理這樣的異常，我們的代碼其實是變得更糟糕了。
回過頭來看這樣的討論，且不說它有沒有價值，至少在我看來是低效的。如果我們有更多的耐心和包容心，我們先聽作者把話說完，仔細傾聽他人寫代碼時的考慮，是不是可以直接避免這樣的討論呢？我們的合作是不是更加順暢呢？
耐心、包容心對于我們的 TL 其實有更高的要求，在面對一些經(jīng)驗稍差的團隊成員寫出來的代碼，有時即便是有非常明顯的問題，我們也需要虛心的耐心的傾聽作者的解釋，包容他的問題，然后合理的給出建議。只有這樣，團隊成員才能感受到自己是受重視的，自己哪里經(jīng)驗還比較欠缺，要往哪方面去努力。
幾個小建議
我們每天和不同背景不同經(jīng)歷的團隊成員進行合作，大家可能很容易的產(chǎn)生分歧，我們無意間發(fā)表的觀點也可能會傷到他人的自尊。如何讓自己有更好的耐心和包容心？這個問題可能是每一個作為成熟的職場人所必須要經(jīng)常思考和練習的。只有每個人都做好了這些，我們在日常工作中才能更順暢的交流，更高效的合作，更和諧的相處。
ThoughtWorks 是一個反饋文化很濃厚的公司，反饋的技巧對于培養(yǎng)自己更好的耐心和包容心同樣適用。要想有好的反饋效果，我們通常不是直接指出對方的問題，因為我們觀察到的對方的問題一般都只是根據(jù)事實的推測，內(nèi)在原因我們未必知道。那么第一步是講事實，傾聽他人的解釋，然后驗證自己的假設(shè)。如果對方根本沒有這個問題（先前的假設(shè)不存在），那么我們的反饋自然也就不存在。如果真的存在問題，應該適當引導他，讓他自己發(fā)現(xiàn)做的不對，然后主動的去改正，我們當然也可以在這個時候分享一些自己的經(jīng)驗，給出一些自己的建議。這樣的反饋其實很需要耐心和包容心。
我個人的另一些經(jīng)驗來自卡耐基《人性的弱點》這本書。相信很多同學們都看過這本書，書中對于如何指出別人的錯誤，如何提出建議給出了很多很有效的方法。這本書并不是像很多“成功學”的書一樣，似乎我們看了就能成就多么偉大的一番事業(yè)。這本書更多的是教會大家如何去追求內(nèi)心的平靜，如何將自己的社會關(guān)系建立得更加和諧。看完這本書，我們可能會更少的抱怨，更多的付出，同時也更滿足，更幸福。
這里有一些書中內(nèi)容的引用，與大家共勉。
如何指出別人的錯誤？
- 用稱贊和真誠的欣賞開始
- 教導他人時，要做到讓別人不覺得在被教導
- 提出別人不知之事要像是提醒別人遺忘之事
- 尊重他人，間接的指出人們的過錯，使用“如果 xx 那么 xx”
- 在批評對方之前，不妨先談?wù)勀阕约旱腻e誤
- 使錯誤看起來容易改正
- 用請求、建議、商量、贊美、提問的方式進行，別用命令的口吻，保全他人的面子
