03丨沟通：程序员为什么应该爱上交流？
程序员这个群体最开始被社会认知的时候，标签之一就是不善交流。慢慢地，“喜欢玩电脑，不喜欢和人交流”成了大家对程序员的一个刻板印象。作为程序员，我发现工作的时间越久，承担的责任越大，那么交流是一个越来越重要的能力。
在这一讲里，我们就来聊聊程序员如何进行高质量的交流。当然了，你可能会想，我不喜欢交流照样工作得很顺利，可是，交流带来的好处也就体会不到了。
当然了，在开始前，让我们先想想，为什么我们会不爱交流呢？
为什么程序员普遍不喜欢交流？
其实，是不是喜欢和人交流绝大部分是由性格决定的，和职业无关。可能程序员这个行业，相比其他行业，吸引了更多的不喜欢交流的人吧。但是除了性格之外，确实有些客观因素影响了交流的积极性。
工作被打断严重影响效率
我觉得这个绝对应该是排在第一条的。和人交流一般需要约好时间，到了时间不得不放下手头的工作。有时候也会有人主动过来，随便聊点东西。无论是哪种形式，其实都会打断程序员当前的工作。
而所有的程序员，都非常讨厌自己的工作被打断。
交流不能直接帮程序员完成工作
网上有个段子，说程序员和产品经理在开会，讨论到下班才结束。产品经理一看正好到点了，就欢欢喜喜地闪了，留下程序员拿着需求挑灯加班。
会议结束之后，程序员的工作才算真正开始，从利益的角度来说，也难免我们会抵触这种不能帮自己直接完成工作的交流了。
程序员其实只是交流中的“利益受损者”，我们排斥的不是交流本身，而是厌烦交流中时间的“浪费”。
当然，面对面的交流只是一个例子，其实写文档、回邮件、做演示等等都一样，都让程序员感觉是“浪费时间”。
简单来说，没有无缘无故的讨厌。别管程序员嘴里怎么说，心里其实明白，归根结底，还是因为我们觉得这些事情影响了自己的“利益”。
爱上的第一步：正视和人的交流
如果交流有损程序员的利益，那为什么我们还要交流呢？我就写我的代码，写完下班不是挺好的吗？其实这就涉及到一个长期利益和短期利益的问题了。短期来看，少参加一个会，少和人聊两句业务，少被人打断几次，从一个星期的维度看，可能工作确实完成得更快了，加班更少了。
但是从长期发展来看，缺少交流的程序员，很难发展为公司的骨干，升职加薪可能都会被排在后面。我们的工作，真的不止眼前的程序。
在做事情的时候，优秀的交流能力是必须的。如果你能够展示自己在交流能力上的优势，组内外的同事也更愿意和你合作，经理也会优先考虑让你承担更多的责任，对自己的发展有很大的好处。
我认为，交流的好处可以从两个方面来说，一个是输入，一个是输出。
输入
我们都说要创新，要整合资源。其实要想做到这一点，在一个公司里实现成长，就要时刻保持自己获取信息。如果能够重视平时的交流，交流的时候多主动思考，慢慢地，自己收获的关于公司和行业的信息也就越来越多，没准还就能够找到新的突破点，抓住新的机会。
机会都是自己争取的，这句话看似鸡汤，但是背后的道理一定要明白。没有哪个创新是空中楼阁，在现代社会闭门造车也很难成功。只有足够的信息可以在脑子里碰撞，创新的火花才更有可能出现。在外人看来的灵光一闪，背后可能有很深的积累。
输出
现在已经不是一个酒香不怕巷子深的时代了。自己的想法，自己的工作成果，都应该积极主动地向外界输出。输出不一定是什么长篇大论，可以是简单的交流、发邮件、写文档、做工作成果演示等等。通过输出，我们才能慢慢赢得自己的声誉，树立自己的影响力。
养成主动交流的好习惯
当我们意识到交流的重要性之后，就应该慢慢养成主动交流的好习惯。
交流不一定要是非常正视的形式。我们可以闲聊，趁着吃饭或者散步的时间，主动和组内同事，和自己的经理，和自己上下游的关键联系人交流自己的想法以及正在自己做的事情，然后也从对方那里获取相应的信息。
不要让自己做一个小透明，做的事情要让别人知道。同时，也知道别人在做什么，别人遇到了什么问题。别人的问题，就是你潜在的机会。
当然了，我们也可以通过分享会的形式，进行正式演示。这种演示一方面可以展示自己的工作成果，另一方面也可以听取别人的意见，看看自己的工作如何能给更多的人带来价值。
前面说到的交流多偏向于信息交换。其实日常工作中还有很多交流都是为了解决具体的问题。从技巧上而言，这两种类型的交流并没有什么区别。
程序员交流的技巧
换位思考，注意受众
其实人和人之间交流最重要的一点就是换位思考。站在对方的角度理解自己表述的内容，看看能否被正确地接纳和吸收。程序员是一种专业性很强的工种。很多专业技能相关的内容，可能会让非专业人士摸不着头脑。大到一个公司，一个部门，小到一个组，一个项目，都可能有很多专有名词，专用词汇，需要很强的背景知识。
所以我们在交流的时候，首先要进行快速的角色转换，找到对方和自己认知的“最大公约数”，英文叫做“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类的演讲，也是先抛出结论和成果，再去涉及详细的内容。
这样不仅可以让对方马上抓到重点，而且还可以让对方在有疑问的时候，可以带着疑问去阅读后续的细节。
总结
程序员的工作就像是产品。好的交流就像是包装，广告，公关和营销。有了好的产品，还要有好的包装，突出产品特点的广告，及时的公关和合适的的营销，才能赢得市场。没有这些，别人可能根本就不知道你有这么个产品，不知道这个产品能干什么，有什么特点等等。
这里再总结一下，从输入这个角度来说，交流的好处可以分为以下几点：
- 获取更多的信息；
- 理解公司的业务；
- 加深对行业的理解；
- 发现新的机会。
如果在交流中能够输出自己的内容，长期来看，给自己带来如下好处：
- 赢得自己的声誉；
- 树立自己的影响力；
- 赢得同事和经理的信任，承担更大的责任。
充分的交流，并不是“就知道动嘴”，而是一个获取信息，加工信息，给出信息的过程。只有交流了，我们才能知道对方的想法，自己认为的好，可能并不是大家认为的好，自己没有想到的好处，别人可能想到了。我们在日常工作中应该多注意自己交流技巧的培养，养成喜欢和人交流的习惯。工作越久，交流在工作中的地位也就越重要。
思考题
你是一个喜欢交流的程序员吗？你有因为擅长交流而获得什么惊喜吗？欢迎你在留言区留言，我会和你一起交流，也欢迎把这篇文章分享给你的朋友或者同事，一起讨论一下吧！
- 牛牛 👍（21） 💬（4）
的确, 平时的工作很不喜欢被人打断, 尤其是写代码状态很好的时候, 好不容易清楚了的逻辑, 万一被打断, 思路可能就断了, 后来工作越来越多的时候, 被打断是很难免的, 我就学会了todo list, 每周末根据事情的优先级安排下周工作, 并保留1天左右的buffer(处理突发事件或者应对临时需求插入); 每天根据任务完成情况, 动态调整第二天的任务或者加加班(流泪....), 保证周任务或者项目级别的准时性; 同时也学会了拒绝, 不合理的需求尽可能的拒绝; 更重要的可能是trade off, 代码的最优不一定是项目的最优, 当下的最优不一定是全局的最优, 项目是需要先机的, 或许我们应该不止是coding, 还应该关注整个项目的计划, 可能delay的不是项目的排期, 而是项目的生命....
2020-05-22 - icyricky 👍（19） 💬（7）
我是一名运维…我们是轮流值班制，在我不值班的时间，总有开发喜欢过来问一句在吗，就没有下文…即使我工作签名改成我在请直接说问题，还是依然如此，我想问一下老师怎么处理这个情况
2020-05-22 - chewbee 👍（10） 💬（3）
可能是自己性格内向的原因，之前不怎么爱主动与他人交流的习惯，埋头做好自己手头的事，看了老师的文章，认识到主动交流长远来看还是对自己很有帮助，针对性格内向的情况，有什么好的建议，养成主动交流的习惯呢？
2020-05-23 - Bug? Feature! 👍（6） 💬（1）
总结下~ 长期发展来看，缺少交流，很难发展为公司骨干，升值加薪可能都会被排在后面，工作真的不仅仅是眼前的程序。多交流，多沟通，对自己的发展很有好处，同事，领导都更愿意和你合作，让你承担更多的责任。交流要带有足够的信息，先说重点和结论，这样可以让对方马上get到重要的point，而且你还可以顺势去帮忙解读对方的疑问甚至细节。
2020-05-22 - 叶小鍵 👍（5） 💬（1）
只做事不说话，在职场中是不行的，因为你会慢慢变成一个人，没有人在意你，也没有人关心你，也没有朋友，只有陌生人。 工作或是生活都是要需要交流，好的交流如同助力，让你在工作如鱼得水。 要如何做，我觉得初入手，可以把说的话写下来，再来换位思考写，再来试着先说结论再说重点(重点说三条即可)，试试， 若有时间允许的话，晚上睡前进行反思自省，想想今日的说话与工作，好坏在那？可以做什么改善与保持。
2020-06-11 - 我来也 👍（5） 💬（1）
对于换位思考的那一节,比较有共鸣. 就同一个项目,app前端与服务后端交流时,也会有类似的问题. 曾经在项目中就遇到过这样的情况. 前端反馈问题就是: "你们的api接口有问题!" 连api接口的完整url地址都不提供的. 后来反复沟通了很多次后,终于把url带过来了,一看根本就不是我们服务的域名. "你们的数据未推送过来!" 我习惯在相当于网关的地方添加完整的日志,这相当于是我的责任边界. 我提供的相关日志表明数据已经推送过去了. 而前端坚持,他加的断点未被触发,消息肯定没收到,让我去看他们的代码. 后来,还是因为他们的逻辑问题,未触发他的那一段代码.
2020-05-23 - 行与修 👍（5） 💬（1）
我工作中的交流分三类：开发组内，客户，跨部门。前两个都没太大问题，能看的到好处是做之前讨论比较充分了，不至于跑偏，成果也能及时跟客户迭代。倒是跨部门（实施）交流效率不高，主要在两点：一是同样的事情反复说，微信里文字截图看了记不住，为避免零碎整理出的文档也不细看，喜欢直接来问你；二是计划经常变（理由是别的项目怎样怎样），为了推进进度我倒是帮着想主意，但是开发人员的时间又怎么经得起陷入和第三方对接打烂仗呢！老师有啥建议能启发我一下吗？
2020-05-23 - wang_acmilan 👍（5） 💬（1）
关于交流有一点心得:在华为工作时，通过邮件交流是非常普遍的一种形式。我曾在与人的邮件沟通中犯过如下错误: 1.逻辑不清晰，邮件中不描述背景和上下文，有被高层主管在邮件中直接怼过 2.爱加戏，分析一个攻关问题，突出的是自己定位的思路，而不是把问题的结论和下一步计划放到最突出，最容易呈现的地方。浪费了邮件相关收件人的阅读时间？ 后来我的老板给我提了标准邮件的两个要求: 1.邮件发出来以后，不需要让别人再费劲的问你相关信息。这个要求我的邮件尽量的逻辑清晰和内容详实 2.邮件要尽可能的节约别人和你交流的时间。在这点上要注意那些是交流的收件人哪些是抄送；要扣邮件的细节，要注意自己交流和沟通的目的，方法；要明确自己沟通交流后想获取的结果。
2020-05-22 - RecordLiu 👍（4） 💬（1）
程序员写代码被打断真的是太常见了！一开始我很气愤，后来慢慢意识到，被打断也是工作的一部分，这样心态就慢慢变好了。
2020-06-21 - 有学识的兔子 👍（4） 💬（1）
我是看了作者对列举了邮件在工作的几个场景后，决定买这个课程，原因是这是需要补充的部分，也契合课程的标题 职场求生攻略。 我个人不是特别爱交流的人，当然也不反感，对于有质量的交流，对于我来说还是有意义的。 我个人也是朝着增强表达能力方向努力着，这里面最主要的内在动力是 提升自己的价值，参与到更重要的事情上面，而不是重复去做边角料的琐碎事情，这些都需要很好的沟通能力。
2020-05-30 - lesserror 👍（2） 💬（1）
老师，如果给你安排任务的上级你本身不喜欢他，但是平时的工作还需要对接，也经常吵架、撕扯的场景很多，就很难想主动和他说话，这种情况该如何处理呢？
2020-06-26 - hao-kuai 👍（2） 💬（1）
沟通很重要！ 1、沟通本身就是一项很重要的技能；重要到可以减少不必要工作，甚至可以简化工作内容... 2、沟通本身也是一项通用技能； 3、从时间的维度来讲沟通比技术重要！信息的传播途径经历了纸质（书籍、报刊等等）、数字化（收音机->电视->互联网）；下一代的传播媒介是什么还不明确，也许未来程序员不需要写代码
2020-06-15 - pyhhou 👍（2） 💬（2）
老师讲得很好，想请教老师一个关于交流上的问题。今年刚跳槽去到一家不算大的公司，公司内部的技术文档并不是很清楚，刚进去那会，环境什么的都得自己配，对内部所使用的工具没有一个很好的认识，如何运行代码都得问同事。但是我总觉得有些问题确实耽误了别人的时间，比如说如何配置环境，很多周围的老员工都忘了之前是如何配的，很多会回复你让你去问别人。但自己对系统不了解，网上的答案五花八门，到头来时间花了，还是对很多的流程和工具的使用还是不是特别清楚 加上现在因为疫情的影响，都在家工作，有问题也不能面对面交流，大多只能通过文字的形式进行交流，同事也很难到你跟前来看你的问题具体出现在哪。现在，如果遇到的问题不会对我现在项目造成问题，我就尽量不问，或是写下来找时间再问，知道这样不好，但是实在是没有办法。其实我是知道要尽量问一些高质量的问题，不要耽误别人的时间，但对于入职才几个月的人来说，对整体开发流程不熟悉，很多看似很简单的东西，比如业务模块写在哪，工具如何使用等等，都要花上很多时间去了解，有些时候都开始怀疑自己是不是不能胜任这份工作。。。 不知道老师对于刚入职的员工如何交流有没有什么建议？
2020-06-05 - 学要有所用 👍（2） 💬（1）
工作能力强的人不需要怎么交流沟通，也能做好事情，这种人如同一只老虎，但拥有良好的沟通交流能力，则是如虎添翼，如果这只老虎要觅食，安装了双翼的老虎，将能大大缩短觅食时间，提高觅食效率，程序员也是一样，能力强的程序员虽然不需要怎么沟通也能将事情办好，但要是加上良好的沟通能力，则会缩短将事情办好的时间，提高工作效率！这有点像杀鸡，同样是杀鸡，拿普通的刀跟宰牛的刀杀鸡，都是杀鸡，杀几只可能看不出来区别，但是杀成百上千只，那区别就出来了，宰牛刀凭借着其更为锋利的特性，在杀了n多只鸡后，依然锋利如初，而普通的刀在杀了n多鸡后，逐渐变钝，既然如此，为何杀鸡不用宰牛刀呢？是吧！
2020-05-26 - FelixFly 👍（2） 💬（1）
程序员沟通是个大问题，大都不善于沟通，总喜欢自己想，最后弄出来的东西跟本来设计想的差的好远。遇到问题了，也不善于沟通，总喜欢自己找解决方案，有时候可能都有解决方案了，只是自己不知道而已，折腾半天弄出来了，把问题变得超级复杂。
2020-05-26