成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

說說技術人員的耐心和包容心

新聞 前端
情緒化不是一個成熟的職場人士所應有的處事方式,但在我們技術人員中間卻可能更容易的出現。

 [[327222]]

情緒化不是一個成熟的職場人士所應有的處事方式,但在我們技術人員中間卻可能更容易的出現。

  有一個技術人員都知道的很老的段子。如果我們想將一個技術論壇搞火起來,那么我們只需要發一篇帖子——php 是世界上最好的語言。雖然是很老的段子,但現在還常常被人提起,很有意思。

  不僅僅是在論壇中,在我們日常的團隊合作中,其實也常常有這樣的事情?;貞浺幌?,在 Code Review 中,是不是常常有某一行代碼引起了大家的廣泛討論,把整個會議給“搞火”了?大家可能就一個問題討論很久,爭執不下。

  對于這樣的討論,如果大家能心平氣和,互相理解,可能能較快的達成一致,但事實上常常會出現這樣的情況,雙方爭論很久爭執不下,后來可能有人說,“這你都不知道啊”,或者“這我理解不了,你這里明顯有問題”,或者“你說的都好,我用我的方式”,或者“你這里就明顯是在#define true=false”等等。

  在這樣的討論中,我們比較容易情緒化(可能沒有情緒化這么嚴重,這里姑且先用這個詞),演變到最后,原本心平氣和的討論就變成了針對某個個人的互懟,或者直接拒絕交流。一旦情況變成這樣,那么不僅討論效率會大大下降,還會使得彼此心生芥蒂,影響后面的高效合作。

  情緒化不是一個成熟的職場人士所應有的處事方式,但在我們技術人員中間卻可能更容易的出現。因為大家邏輯能力強,,思維也都很敏捷,追求高效率,相對更缺乏耐心。如果大家還能回憶得起來,《社交網絡》中的扎克伯格的形象可能是一個典型的高效技術人員的形象,說話滔滔不絕,做事雷厲風行。我發現身邊的技術人員多多少少都具有點這樣的特質。我自己反思下來,也常常發現自己有不夠耐心的時候。比如某次在和他人交流的時候,對方話還沒說完,我就著急開始講話,然后對方不得已也跟著著急的說“你先聽我說完嘛”。

  正因為如此,我們技術人員可能更需要有一顆耐心和包容心。在沒有寫代碼,而是跟其他人討論交流時,我們有沒有即時的切換狀態,更耐心的對待他人的問題?我們在看別人的代碼的時候,當發現有一些不是自己所推崇的模式的時候,有沒有仔細想一下別人為什么要這么做?我們在遺留代碼上面工作的時候,是不是一邊工作一邊吐槽代碼寫得太爛,而沒有考慮到當時可能有各種各樣的原因?我們是不是只一味的自己講話,而沒有仔細傾聽對方的話?

  一個例子

  印象較深刻的有這樣一個例子,我們的代碼里面有這樣的一段邏輯:

  1. class Something { 
  2.    private Map<String, Object> attributes; 
  3.    public <T> T getAttribute (String name) { 
  4.        return (T) attributes.get(name); 
  5.    } 
  6.    ... 

  當我們在 review 代碼的時候,有人一看到上面這行代碼,還沒等人解釋為什么要這么做就直接說,“這個地方明顯有問題啊,更好的方式是返回一個Option,讓調用方去處理異常”。當作者開始要解釋的時候,他又表現得聽不進去,始終堅持自己是對的。最后由于這個小問題,可能要討論十分鐘。

  這個問題的原因是什么呢?原來是由于Something里面的屬性其實是調用方自己定義的,由于業務的要求,調用方可以定義各種類型的屬性,而當調用方想要獲取某一個屬性的時候,就通過getAttribute獲取。作者的設計意圖是提供一個便捷的類型轉換功能,封裝這類類型強制轉換的代碼,避免這類不好的代碼泄漏到每一個調用此方法的地方,而假設調用方確定的知道所查詢的屬性是什么類型(屬性是調用方自己定義的)。如果這里的類型轉換出錯,那么會拋出一個運行時異常,這是寫代碼時就必須要處理的 bug。

  這里的分析合情合理,在我看來是完全可以接受的。試想,如果我們返回一個Option,每一個調用的地方都需要處理類型轉換失敗的情況,而調用方要如何處理呢?似乎也只能將其拋給更上層。其實這里作為調用方可能會很奇怪,為啥我明明知道不會拋出異常,還需要顯示的處理異常呢?而且由于這樣的調用方可能很多,每個地方都需要處理這樣的異常,我們的代碼其實是變得更糟糕了。
回過頭來看這樣的討論,且不說它有沒有價值,至少在我看來是低效的。如果我們有更多的耐心和包容心,我們先聽作者把話說完,仔細傾聽他人寫代碼時的考慮,是不是可以直接避免這樣的討論呢?我們的合作是不是更加順暢呢?

  耐心、包容心對于我們的 TL 其實有更高的要求,在面對一些經驗稍差的團隊成員寫出來的代碼,有時即便是有非常明顯的問題,我們也需要虛心的耐心的傾聽作者的解釋,包容他的問題,然后合理的給出建議。只有這樣,團隊成員才能感受到自己是受重視的,自己哪里經驗還比較欠缺,要往哪方面去努力。

  幾個小建議

  我們每天和不同背景不同經歷的團隊成員進行合作,大家可能很容易的產生分歧,我們無意間發表的觀點也可能會傷到他人的自尊。如何讓自己有更好的耐心和包容心?這個問題可能是每一個作為成熟的職場人所必須要經常思考和練習的。只有每個人都做好了這些,我們在日常工作中才能更順暢的交流,更高效的合作,更和諧的相處。

  ThoughtWorks 是一個反饋文化很濃厚的公司,反饋的技巧對于培養自己更好的耐心和包容心同樣適用。要想有好的反饋效果,我們通常不是直接指出對方的問題,因為我們觀察到的對方的問題一般都只是根據事實的推測,內在原因我們未必知道。那么第一步是講事實,傾聽他人的解釋,然后驗證自己的假設。如果對方根本沒有這個問題(先前的假設不存在),那么我們的反饋自然也就不存在。如果真的存在問題,應該適當引導他,讓他自己發現做的不對,然后主動的去改正,我們當然也可以在這個時候分享一些自己的經驗,給出一些自己的建議。這樣的反饋其實很需要耐心和包容心。

  我個人的另一些經驗來自卡耐基《人性的弱點》這本書。相信很多同學們都看過這本書,書中對于如何指出別人的錯誤,如何提出建議給出了很多很有效的方法。這本書并不是像很多“成功學”的書一樣,似乎我們看了就能成就多么偉大的一番事業。這本書更多的是教會大家如何去追求內心的平靜,如何將自己的社會關系建立得更加和諧??赐赀@本書,我們可能會更少的抱怨,更多的付出,同時也更滿足,更幸福。

  這里有一些書中內容的引用,與大家共勉。

  如何指出別人的錯誤?

  • 用稱贊和真誠的欣賞開始
  • 教導他人時,要做到讓別人不覺得在被教導
  • 提出別人不知之事要像是提醒別人遺忘之事
  • 尊重他人,間接的指出人們的過錯,使用“如果 xx 那么 xx”
  • 在批評對方之前,不妨先談談你自己的錯誤
  • 使錯誤看起來容易改正
  • 用請求、建議、商量、贊美、提問的方式進行,別用命令的口吻,保全他人的面子

 

責任編輯:張燕妮 來源: insights.thoughtworks.cn
相關推薦

2017-09-14 17:12:58

2009-04-17 10:13:05

技術人員晉升職場

2014-01-23 11:11:31

2012-09-20 09:31:41

技術技術人員技術開發

2009-10-14 10:18:53

薪酬

2009-12-25 14:17:36

ADO錯誤

2012-01-13 15:48:21

IT技術人員

2018-10-09 10:57:48

技術KPI考核

2013-08-06 15:16:27

技術人創業開發者創業移動互聯網創業

2012-05-10 10:23:10

技術人員開發

2020-09-22 15:30:19

技術研發思維

2013-06-20 09:28:24

2013-08-06 09:42:59

技術人員面試

2015-05-11 13:57:15

IT技術人員思考問題

2018-06-21 15:23:36

2009-11-30 16:36:35

IBM

2009-12-24 17:11:09

ADO與RDO

2010-08-09 17:08:13

IT技術人

2013-09-30 10:16:32

博客技術人員

2011-05-07 15:08:21

點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 一二三区av| 91社影院在线观看 | 国产精品网址 | 欧美日韩视频网站 | 黄视频网站在线 | 日本不卡一区二区三区在线观看 | 性一交一乱一伦视频免费观看 | 在线国产欧美 | 观看av | 五月天婷婷激情 | 欧美综合精品 | 91网在线观看 | 国产一区久久精品 | 日韩视频精品 | 91麻豆精品国产91久久久久久 | 亚洲36d大奶网 | 国产一区视频在线 | 白浆在线 | 黄久久久| 国产精品成人一区 | 玖玖玖av| 亚洲精品99999 | 精品久久久久久久久久久 | 日韩欧美在线观看一区 | 欧美一区二区精品 | 日韩中文字幕 | 91人人看 | 手机av在线| 国产xxxx在线 | 成人国产精品一级毛片视频毛片 | 97视频在线观看网站 | 久久久久久亚洲欧洲 | 亚洲综合色 | 国产一区二区在线免费观看 | 欧美一级片在线看 | 久热久草| 久久成人精品视频 | 亚洲国产中文字幕 | 婷婷色网 | 美女黄18岁以下禁止观看 | 午夜免费视频 |