慷慨大方地交流
关于最后一点，我想了很多。在对我的想法的所有描述中，我认为最好的是Nat Friedman在最近一次全体会议中所做的介绍。他说过类似这样的话：“我们彼此之间的交流应该遵循稳健性原则：发送时要保守，接收时要开放。”他还鼓励我们坚持宽容性原则，尤其是在非常困难的情况下与对方沟通的时候。但是我认为，高绩效团队会百分之百遵循这个原则。
我非常喜欢这种框架化，因为它让我想起了多年前我在codebar做志愿者时所经历的导师培训。“假设你接触到的每个学生都知识有限，但智慧无限。”这样一来，指导者就有责任确保他们的解释容易理解——考虑到老师和学生之间固有的权力不平衡，这是传达附加的情绪劳务的一种很好的方式。
同事之间慷慨大方地交流意味着，我们假设任何时候任何人问问题时：
·已经做了基本的研究，如已经用谷歌进行了搜索；
·他们是因为在任何地方都无法找到答案才找人问。因为这个地方很难找，或者根本不存在。
换句话说：假设你的同伴是一个有能力、聪明、通情达理的人，他们问问题是因为他们不了解上下文，虽然他们已经设法了解过。
当你开始寻求帮助时，你的上下文信息和工作经验被不断地“四舍五入”，我都不知道该怎么表达这是多么令人沮丧。是的，这里面有性别因素，但这超出了我们现在的讨论范围。以前，我曾发过多条推特，表达了当别人认为你实际上远没有那么经验丰富和知识渊博时的沮丧。当然，别人是不可能真正知道的，无所不知是不可能的！但是，这里有一个折中方案，也是一个合理的要求：慷慨。
像下面这样就不够慷慨：
我：嗨，这里为什么有一个负载均衡器？
X：负载均衡器用于将请求分发到多个服务上，这样我们就不会遭受DDoS攻击了！这里有一些文章介绍负载均衡器的基础知识，以及从理论上讲我们为什么要使用它们！
我：好的，但我问的不是这个。我知道负载均衡器是什么。我只是想了解下，在架构决策时，为什么要把**HAproxy放在这个特定的服务前面。
X：奥！好吧，你应该直接这样问！
相反，下面这样就是慷慨的：
我：嗨，这里为什么有一个负载均衡器？
X：我猜你是在问我们为什么选择HAproxy，以及为什么选择这些服务。如果不是的话，现在就告诉我。
我：对，就是那样！谢谢你先确认我的问题。
X：不用客气。是这样的，18个月前，当我们构建这个系统时……
上面两种互动方式的关键区别在于，在慷慨的互动中，在给出答案之前，回答者会确认他们对问题的假设，进而核实提问者的上下文层级和意图。采用慷慨的交流方式有非常积极的影响：首先，注意到交流时所使用的词汇减少了吗？他们实际上可以更快地得到答案。其次，没有产生不必要的摩擦。两个人团结一致消除了不确定性，而不是纠结于每个人知道多少，如果是后者，也许最终他们也可以得出答案，但同时也失去了一些信任和善意。
如果你有在高效软件开发团队工作的经验，或者花时间做过这方面的研究总结，请留言告诉我们你的感受和想法！