摘要：情绪化不是一个成熟的职场人士所应有的处事方式，但在我们技术人员中间却可能更容易的出现。
有一个技术人员都知道的很老的段子。如果我们想将一个技术论坛搞火起来，那么我们只需要发一篇帖子——php 是世界上最好的语言。虽然是很老的段子，但现在还常常被人提起，很有意思。
不仅仅是在论坛中，在我们日常的团队合作中，其实也常常有这样的事情。回忆一下，在 Code Review 中，是不是常常有某一行代码引起了大家的广泛讨论，把整个会议给“搞火”了？大家可能就一个问题讨论很久，争执不下。
对于这样的讨论，如果大家能心平气和，互相理解，可能能较快的达成一致，但事实上常常会出现这样的情况，双方争论很久争执不下，后来可能有人说，“这你都不知道啊”，或者“这我理解不了，你这里明显有问题”，或者“你说的都好，我用我的方式”，或者“你这里就明显是在#define true=false”等等。
在这样的讨论中，我们比较容易情绪化（可能没有情绪化这么严重，这里姑且先用这个词），演变到最后，原本心平气和的讨论就变成了针对某个个人的互怼，或者直接拒绝交流。一旦情况变成这样，那么不仅讨论效率会大大下降，还会使得彼此心生芥蒂，影响后面的高效合作。
情绪化不是一个成熟的职场人士所应有的处事方式，但在我们技术人员中间却可能更容易的出现。因为大家逻辑能力强，，思维也都很敏捷，追求高效率，相对更缺乏耐心。如果大家还能回忆得起来，《社交网络》中的扎克伯格的形象可能是一个典型的高效技术人员的形象，说话滔滔不绝，做事雷厉风行。我发现身边的技术人员多多少少都具有点这样的特质。我自己反思下来，也常常发现自己有不够耐心的时候。比如某次在和他人交流的时候，对方话还没说完，我就着急开始讲话，然后对方不得已也跟着着急的说“你先听我说完嘛”。
正因为如此，我们技术人员可能更需要有一颗耐心和包容心。在没有写代码，而是跟其他人讨论交流时，我们有没有即时的切换状态，更耐心的对待他人的问题？我们在看别人的代码的时候，当发现有一些不是自己所推崇的模式的时候，有没有仔细想一下别人为什么要这么做？我们在遗留代码上面工作的时候，是不是一边工作一边吐槽代码写得太烂，而没有考虑到当时可能有各种各样的原因？我们是不是只一味的自己讲话，而没有仔细倾听对方的话？
一个例子
印象较深刻的有这样一个例子，我们的代码里面有这样的一段逻辑：
class Something { private Map<String, Object> attributes; public <T> T getAttribute (String name) { return (T) attributes.get(name); } ... }
当我们在 review 代码的时候，有人一看到上面这行代码，还没等人解释为什么要这么做就直接说，“这个地方明显有问题啊，更好的方式是返回一个Option，让调用方去处理异常”。当作者开始要解释的时候，他又表现得听不进去，始终坚持自己是对的。最后由于这个小问题，可能要讨论十分钟。
这个问题的原因是什么呢？原来是由于Something里面的属性其实是调用方自己定义的，由于业务的要求，调用方可以定义各种类型的属性，而当调用方想要获取某一个属性的时候，就通过getAttribute获取。作者的设计意图是提供一个便捷的类型转换功能，封装这类类型强制转换的代码，避免这类不好的代码泄漏到每一个调用此方法的地方，而假设调用方确定的知道所查询的属性是什么类型（属性是调用方自己定义的）。如果这里的类型转换出错，那么会抛出一个运行时异常，这是写代码时就必须要处理的 bug。
这里的分析合情合理，在我看来是完全可以接受的。试想，如果我们返回一个Option，每一个调用的地方都需要处理类型转换失败的情况，而调用方要如何处理呢？似乎也只能将其抛给更上层。其实这里作为调用方可能会很奇怪，为啥我明明知道不会抛出异常，还需要显示的处理异常呢？而且由于这样的调用方可能很多，每个地方都需要处理这样的异常，我们的代码其实是变得更糟糕了。
回过头来看这样的讨论，且不说它有没有价值，至少在我看来是低效的。如果我们有更多的耐心和包容心，我们先听作者把话说完，仔细倾听他人写代码时的考虑，是不是可以直接避免这样的讨论呢？我们的合作是不是更加顺畅呢？
耐心、包容心对于我们的 TL 其实有更高的要求，在面对一些经验稍差的团队成员写出来的代码，有时即便是有非常明显的问题，我们也需要虚心的耐心的倾听作者的解释，包容他的问题，然后合理的给出建议。只有这样，团队成员才能感受到自己是受重视的，自己哪里经验还比较欠缺，要往哪方面去努力。
几个小建议
我们每天和不同背景不同经历的团队成员进行合作，大家可能很容易的产生分歧，我们无意间发表的观点也可能会伤到他人的自尊。如何让自己有更好的耐心和包容心？这个问题可能是每一个作为成熟的职场人所必须要经常思考和练习的。只有每个人都做好了这些，我们在日常工作中才能更顺畅的交流，更高效的合作，更和谐的相处。
ThoughtWorks 是一个反馈文化很浓厚的公司，反馈的技巧对于培养自己更好的耐心和包容心同样适用。要想有好的反馈效果，我们通常不是直接指出对方的问题，因为我们观察到的对方的问题一般都只是根据事实的推测，内在原因我们未必知道。那么第一步是讲事实，倾听他人的解释，然后验证自己的假设。如果对方根本没有这个问题（先前的假设不存在），那么我们的反馈自然也就不存在。如果真的存在问题，应该适当引导他，让他自己发现做的不对，然后主动的去改正，我们当然也可以在这个时候分享一些自己的经验，给出一些自己的建议。这样的反馈其实很需要耐心和包容心。
我个人的另一些经验来自卡耐基《人性的弱点》这本书。相信很多同学们都看过这本书，书中对于如何指出别人的错误，如何提出建议给出了很多很有效的方法。这本书并不是像很多“成功学”的书一样，似乎我们看了就能成就多么伟大的一番事业。这本书更多的是教会大家如何去追求内心的平静，如何将自己的社会关系建立得更加和谐。看完这本书，我们可能会更少的抱怨，更多的付出，同时也更满足，更幸福。
这里有一些书中内容的引用，与大家共勉。
如何指出别人的错误？
- 用称赞和真诚的欣赏开始
- 教导他人时，要做到让别人不觉得在被教导
- 提出别人不知之事要像是提醒别人遗忘之事
- 尊重他人，间接的指出人们的过错，使用“如果 xx 那么 xx”
- 在批评对方之前，不妨先谈谈你自己的错误
- 使错误看起来容易改正
- 用请求、建议、商量、赞美、提问的方式进行，别用命令的口吻，保全他人的面子