程序员这个群体最开始被社会认知的时候，标签之一就是不善交流。慢慢地，“喜欢玩电脑，不喜欢和人交流”成了大家对程序员的一个刻板印象。作为程序员，我发现工作的时间越久，承担的责任越大，那么交流是一个越来越重要的能力。
在这一讲里，我们就来聊聊程序员如何进行高质量的交流。当然了，你可能会想，我不喜欢交流照样工作得很顺利，可是，交流带来的好处也就体会不到了。
当然了，在开始前，让我们先想想，为什么我们会不爱交流呢？
为什么程序员普遍不喜欢交流？
其实，是不是喜欢和人交流绝大部分是由性格决定的，和职业无关。可能程序员这个行业，相比其他行业，吸引了更多的不喜欢交流的人吧。但是除了性格之外，确实有些客观因素影响了交流的积极性。
工作被打断严重影响效率
我觉得这个绝对应该是排在第一条的。和人交流一般需要约好时间，到了时间不得不放下手头的工作。有时候也会有人主动过来，随便聊点东西。无论是哪种形式，其实都会打断程序员当前的工作。
而所有的程序员，都非常讨厌自己的工作被打断。
交流不能直接帮程序员完成工作
网上有个段子，说程序员和产品经理在开会，讨论到下班才结束。产品经理一看正好到点了，就欢欢喜喜地闪了，留下程序员拿着需求挑灯加班。
会议结束之后，程序员的工作才算真正开始，从利益的角度来说，也难免我们会抵触这种不能帮自己直接完成工作的交流了。
程序员其实只是交流中的“利益受损者”，我们排斥的不是交流本身，而是厌烦交流中时间的“浪费”。
当然，面对面的交流只是一个例子，其实写文档、回邮件、做演示等等都一样，都让程序员感觉是“浪费时间”。
简单来说，没有无缘无故的讨厌。别管程序员嘴里怎么说，心里其实明白，归根结底，还是因为我们觉得这些事情影响了自己的“利益”。
爱上的第一步：正视和人的交流
如果交流有损程序员的利益，那为什么我们还要交流呢？我就写我的代码，写完下班不是挺好的吗？其实这就涉及到一个长期利益和短期利益的问题了。短期来看，少参加一个会，少和人聊两句业务，少被人打断几次，从一个星期的维度看，可能工作确实完成得更快了，加班更少了。
但是从长期发展来看，缺少交流的程序员，很难发展为公司的骨干，升职加薪可能都会被排在后面。我们的工作，真的不止眼前的程序。
在做事情的时候，优秀的交流能力是必须的。如果你能够展示自己在交流能力上的优势，组内外的同事也更愿意和你合作，经理也会优先考虑让你承担更多的责任，对自己的发展有很大的好处。
我认为，交流的好处可以从两个方面来说，一个是输入，一个是输出。
输入
我们都说要创新，要整合资源。其实要想做到这一点，在一个公司里实现成长，就要时刻保持自己获取信息。如果能够重视平时的交流，交流的时候多主动思考，慢慢地，自己收获的关于公司和行业的信息也就越来越多，没准还就能够找到新的突破点，抓住新的机会。
机会都是自己争取的，这句话看似鸡汤，但是背后的道理一定要明白。没有哪个创新是空中楼阁，在现代社会闭门造车也很难成功。只有足够的信息可以在脑子里碰撞，创新的火花才更有可能出现。在外人看来的灵光一闪，背后可能有很深的积累。
输出
现在已经不是一个酒香不怕巷子深的时代了。自己的想法，自己的工作成果，都应该积极主动地向外界输出。输出不一定是什么长篇大论，可以是简单的交流、发邮件、写文档、做工作成果演示等等。通过输出，我们才能慢慢赢得自己的声誉，树立自己的影响力。
养成主动交流的好习惯
当我们意识到交流的重要性之后，就应该慢慢养成主动交流的好习惯。
交流不一定要是非常正视的形式。我们可以闲聊，趁着吃饭或者散步的时间，主动和组内同事，和自己的经理，和自己上下游的关键联系人交流自己的想法以及正在自己做的事情，然后也从对方那里获取相应的信息。
不要让自己做一个小透明，做的事情要让别人知道。同时，也知道别人在做什么，别人遇到了什么问题。别人的问题，就是你潜在的机会。
当然了，我们也可以通过分享会的形式，进行正式演示。这种演示一方面可以展示自己的工作成果，另一方面也可以听取别人的意见，看看自己的工作如何能给更多的人带来价值。
前面说到的交流多偏向于信息交换。其实日常工作中还有很多交流都是为了解决具体的问题。从技巧上而言，这两种类型的交流并没有什么区别。
程序员交流的技巧
换位思考，注意受众
其实人和人之间交流最重要的一点就是换位思考。站在对方的角度理解自己表述的内容，看看能否被正确地接纳和吸收。程序员是一种专业性很强的工种。很多专业技能相关的内容，可能会让非专业人士摸不着头脑。大到一个公司，一个部门，小到一个组，一个项目，都可能有很多专有名词，专用词汇，需要很强的背景知识。
所以我们在交流的时候，首先要进行快速的角色转换，找到对方和自己认知的“最大公约数”，英文叫做“on the same page”。然后对于交流中需要补充的知识做简单的介绍，比如系统特点，专有名词的介绍等等，避免受众一路带着问号听你说，最后对话变成了“鸡同鸭讲”。
举个例子。如果我们发现上游的订单数据有问题，那么我们可能需要找同组的人帮忙看。这时候，我们可以找组内相关的同事说，帮忙看看订单的数据是不是有问题。组内的同事对系统都是很熟悉的，不需要交代太多上下文。
如果我们发现确实是上游的数据有问题，有些字段缺失了，需要上游系统配合帮忙查找问题。这时候可以发邮件给上游系统。我给出两个邮件标题，你觉得哪个更好呢？
- 订单数据在OrderProcessor引起异常
- 从3月15日起，来自Kafka的订单数据，缺失了OrderingTime，OrderName字段
第一个标题，明显没有分清交流对象。OrderProcessor是自己组内项目的代码，这明显不是两个组的责任交界。数据在进入OrderProcessor之前，还有很多步骤，不能确定是上游发的数据的问题。难道你想让上游的组去看你的代码，帮你找自己代码的问题吗？
第二个标题，很清晰明确。上游数据发到Kafka，这是大家责任的交界处。时间，问题也都交代得很清楚。上游的组完全可以以此为起点，向后查找自己的问题。
简单来说，既要让对方听明白，也要让对方听到自己应该听的。交流不是应付差事，说完拉倒，也不要只顾自己说。
交流要带有足够的信息
我们来看一个教科书般的交流失败的例子：
A问：“订单信息数据在HDFS上有吗？”
B说：“有。”
B的回答没错，但是也没啥用。A的问题明显是想知道订单信息在HDFS的具体位置，而非只是有或者没有。B如果知道具体在那里，就应该一并告诉A；B如果不知道，也应该回答“有，但是我不知道在那里。”如果B知道谁可能会知道，那么应该一并告诉A。这样，一次交流，基本就可以结束了。
再以上面订单数据的问题举例。使用了正确的邮件标题，内容也要足够翔实。邮件内容应该包含如下信息：
- 证明订单信息并非一直缺失这部分数据，并拿出数据，附带数据的详细来源。
- 证明现在的订单数据并非所有的消息都缺失这部分数据，并找出缺失数据的消息ID和没有缺失数据的消息ID、时间等追踪信息，以便对方定位问题。
用数据说话，数据出处要清晰；推理条理要清晰，事情的来龙去脉要清晰。有时候写重要的邮件和文档，就像写论文一样。
先说重点和结论
这一条规则适用于所有场合。日常中普通的交流也是，如果带着明确的目的，那么就要先说出自己的结论和想法；如果是写邮件和文档，内容翔实的一个副作用是难免冗长。这时候应该注意，先把结论抛出来，再写细节。如果是PPT类的演讲，也是先抛出结论和成果，再去涉及详细的内容。
这样不仅可以让对方马上抓到重点，而且还可以让对方在有疑问的时候，可以带着疑问去阅读后续的细节。
总结
程序员的工作就像是产品。好的交流就像是包装，广告，公关和营销。有了好的产品，还要有好的包装，突出产品特点的广告，及时的公关和合适的的营销，才能赢得市场。没有这些，别人可能根本就不知道你有这么个产品，不知道这个产品能干什么，有什么特点等等。
这里再总结一下，从输入这个角度来说，交流的好处可以分为以下几点：
- 获取更多的信息；
- 理解公司的业务；
- 加深对行业的理解；
- 发现新的机会。
如果在交流中能够输出自己的内容，长期来看，给自己带来如下好处：
- 赢得自己的声誉；
- 树立自己的影响力；
- 赢得同事和经理的信任，承担更大的责任。
充分的交流，并不是“就知道动嘴”，而是一个获取信息，加工信息，给出信息的过程。只有交流了，我们才能知道对方的想法，自己认为的好，可能并不是大家认为的好，自己没有想到的好处，别人可能想到了。我们在日常工作中应该多注意自己交流技巧的培养，养成喜欢和人交流的习惯。工作越久，交流在工作中的地位也就越重要。
思考题
你是一个喜欢交流的程序员吗？你有因为擅长交流而获得什么惊喜吗？欢迎你在留言区留言，我会和你一起交流，也欢迎把这篇文章分享给你的朋友或者同事，一起讨论一下吧！
精选留言
2020-05-22 10:07:26
2020-05-22 08:43:12
2020-05-23 23:33:45
2020-05-22 10:33:55
长期发展来看，缺少交流，很难发展为公司骨干，升值加薪可能都会被排在后面，工作真的不仅仅是眼前的程序。多交流，多沟通，对自己的发展很有好处，同事，领导都更愿意和你合作，让你承担更多的责任。交流要带有足够的信息，先说重点和结论，这样可以让对方马上get到重要的point，而且你还可以顺势去帮忙解读对方的疑问甚至细节。
2020-06-11 23:11:40
工作或是生活都是要需要交流，好的交流如同助力，让你在工作如鱼得水。
要如何做，我觉得初入手，可以把说的话写下来，再来换位思考写，再来试着先说结论再说重点(重点说三条即可)，试试，
若有时间允许的话，晚上睡前进行反思自省，想想今日的说话与工作，好坏在那？可以做什么改善与保持。
2020-05-23 10:12:14
就同一个项目,app前端与服务后端交流时,也会有类似的问题.
曾经在项目中就遇到过这样的情况.
前端反馈问题就是:
"你们的api接口有问题!"
连api接口的完整url地址都不提供的.
后来反复沟通了很多次后,终于把url带过来了,一看根本就不是我们服务的域名.
"你们的数据未推送过来!"
我习惯在相当于网关的地方添加完整的日志,这相当于是我的责任边界.
我提供的相关日志表明数据已经推送过去了.
而前端坚持,他加的断点未被触发,消息肯定没收到,让我去看他们的代码.
后来,还是因为他们的逻辑问题,未触发他的那一段代码.
2020-05-23 08:56:51
2020-05-22 09:23:02
1.逻辑不清晰，邮件中不描述背景和上下文，有被高层主管在邮件中直接怼过
2.爱加戏，分析一个攻关问题，突出的是自己定位的思路，而不是把问题的结论和下一步计划放到最突出，最容易呈现的地方。浪费了邮件相关收件人的阅读时间？
后来我的老板给我提了标准邮件的两个要求:
1.邮件发出来以后，不需要让别人再费劲的问你相关信息。这个要求我的邮件尽量的逻辑清晰和内容详实
2.邮件要尽可能的节约别人和你交流的时间。在这点上要注意那些是交流的收件人哪些是抄送；要扣邮件的细节，要注意自己交流和沟通的目的，方法；要明确自己沟通交流后想获取的结果。
2020-06-21 15:11:19
2020-05-30 17:10:40
我个人不是特别爱交流的人，当然也不反感，对于有质量的交流，对于我来说还是有意义的。
我个人也是朝着增强表达能力方向努力着，这里面最主要的内在动力是 提升自己的价值，参与到更重要的事情上面，而不是重复去做边角料的琐碎事情，这些都需要很好的沟通能力。
2020-06-26 19:21:58
2020-06-15 16:52:47
1、沟通本身就是一项很重要的技能；重要到可以减少不必要工作，甚至可以简化工作内容...
2、沟通本身也是一项通用技能；
3、从时间的维度来讲沟通比技术重要！信息的传播途径经历了纸质（书籍、报刊等等）、数字化（收音机->电视->互联网）；下一代的传播媒介是什么还不明确，也许未来程序员不需要写代码
2020-06-05 02:04:24
加上现在因为疫情的影响，都在家工作，有问题也不能面对面交流，大多只能通过文字的形式进行交流，同事也很难到你跟前来看你的问题具体出现在哪。现在，如果遇到的问题不会对我现在项目造成问题，我就尽量不问，或是写下来找时间再问，知道这样不好，但是实在是没有办法。其实我是知道要尽量问一些高质量的问题，不要耽误别人的时间，但对于入职才几个月的人来说，对整体开发流程不熟悉，很多看似很简单的东西，比如业务模块写在哪，工具如何使用等等，都要花上很多时间去了解，有些时候都开始怀疑自己是不是不能胜任这份工作。。。
不知道老师对于刚入职的员工如何交流有没有什么建议？
2020-05-26 19:56:37
2020-05-26 15:26:59
2020-05-24 12:17:34
2020-05-22 09:37:34
2020-05-22 09:26:18
2020-05-22 08:38:05
2022-04-16 12:24:20
1. 听障原因导致很多事情都没有办法第一遍就能够听清和理解别人说的话的意思，这个问题有什么好的解决方案么？
2. 由于听障，领导和同事并不是很放心我，所以需要随时问我进度，我对此感觉很烦，我想知道有什么能够让他们放心，不会随时来打扰我工作呢？
3. 听障在沟通交流上存在的困难，可以在哪些方面得到补充和加强，从而能够进一步融入团队，升职加薪，而不是变成小透明呢？