# 03丨沟通：程序员为什么应该爱上交流？

    程序员这个群体最开始被社会认知的时候，标签之一就是不善交流。慢慢地，“喜欢玩电脑，不喜欢和人交流”成了大家对程序员的一个刻板印象。作为程序员，我发现工作的时间越久，承担的责任越大，那么交流是一个越来越重要的能力。

在这一讲里，我们就来聊聊程序员如何进行高质量的交流。当然了，你可能会想，我不喜欢交流照样工作得很顺利，可是，交流带来的好处也就体会不到了。

当然了，在开始前，让我们先想想，为什么我们会不爱交流呢？

## 为什么程序员普遍不喜欢交流？

其实，是不是喜欢和人交流绝大部分是由性格决定的，和职业无关。可能程序员这个行业，相比其他行业，吸引了更多的不喜欢交流的人吧。但是除了性格之外，确实有些客观因素影响了交流的积极性。

### 工作被打断严重影响效率

我觉得这个绝对应该是排在第一条的。和人交流一般需要约好时间，到了时间不得不放下手头的工作。有时候也会有人主动过来，随便聊点东西。无论是哪种形式，其实都会打断程序员当前的工作。

而所有的程序员，都非常讨厌自己的工作被打断。

### 交流不能直接帮程序员完成工作

网上有个段子，说程序员和产品经理在开会，讨论到下班才结束。产品经理一看正好到点了，就欢欢喜喜地闪了，留下程序员拿着需求挑灯加班。

会议结束之后，程序员的工作才算真正开始，从利益的角度来说，也难免我们会抵触这种不能帮自己直接完成工作的交流了。

程序员其实只是交流中的“利益受损者”，我们排斥的不是交流本身，而是厌烦交流中时间的“浪费”。

当然，面对面的交流只是一个例子，其实写文档、回邮件、做演示等等都一样，都让程序员感觉是“浪费时间”。

简单来说，没有无缘无故的讨厌。别管程序员嘴里怎么说，心里其实明白，归根结底，还是因为我们觉得这些事情影响了自己的“利益”。

## 爱上的第一步：正视和人的交流

如果交流有损程序员的利益，那为什么我们还要交流呢？我就写我的代码，写完下班不是挺好的吗？其实这就涉及到一个长期利益和短期利益的问题了。短期来看，少参加一个会，少和人聊两句业务，少被人打断几次，从一个星期的维度看，可能工作确实完成得更快了，加班更少了。

但是从长期发展来看，缺少交流的程序员，很难发展为公司的骨干，升职加薪可能都会被排在后面。我们的工作，真的不止眼前的程序。

在做事情的时候，优秀的交流能力是必须的。如果你能够展示自己在交流能力上的优势，组内外的同事也更愿意和你合作，经理也会优先考虑让你承担更多的责任，对自己的发展有很大的好处。

我认为，交流的好处可以从两个方面来说，一个是输入，一个是输出。

### 输入

我们都说要创新，要整合资源。其实要想做到这一点，在一个公司里实现成长，就要时刻保持自己获取信息。如果能够重视平时的交流，交流的时候多主动思考，慢慢地，自己收获的关于公司和行业的信息也就越来越多，没准还就能够找到新的突破点，抓住新的机会。

机会都是自己争取的，这句话看似鸡汤，但是背后的道理一定要明白。没有哪个创新是空中楼阁，在现代社会闭门造车也很难成功。只有足够的信息可以在脑子里碰撞，创新的火花才更有可能出现。在外人看来的灵光一闪，背后可能有很深的积累。

### 输出

现在已经不是一个酒香不怕巷子深的时代了。自己的想法，自己的工作成果，都应该积极主动地向外界输出。输出不一定是什么长篇大论，可以是简单的交流、发邮件、写文档、做工作成果演示等等。通过输出，我们才能慢慢赢得自己的声誉，树立自己的影响力。

### 养成主动交流的好习惯

当我们意识到交流的重要性之后，就应该慢慢养成主动交流的好习惯。

交流不一定要是非常正视的形式。我们可以闲聊，趁着吃饭或者散步的时间，主动和组内同事，和自己的经理，和自己上下游的关键联系人交流自己的想法以及正在自己做的事情，然后也从对方那里获取相应的信息。

不要让自己做一个小透明，做的事情要让别人知道。同时，也知道别人在做什么，别人遇到了什么问题。别人的问题，就是你潜在的机会。

当然了，我们也可以通过分享会的形式，进行正式演示。这种演示一方面可以展示自己的工作成果，另一方面也可以听取别人的意见，看看自己的工作如何能给更多的人带来价值。

前面说到的交流多偏向于信息交换。其实日常工作中还有很多交流都是为了解决具体的问题。从技巧上而言，这两种类型的交流并没有什么区别。

## 程序员交流的技巧

### 换位思考，注意受众

其实人和人之间交流最重要的一点就是换位思考。站在对方的角度理解自己表述的内容，看看能否被正确地接纳和吸收。程序员是一种专业性很强的工种。很多专业技能相关的内容，可能会让非专业人士摸不着头脑。大到一个公司，一个部门，小到一个组，一个项目，都可能有很多专有名词，专用词汇，需要很强的背景知识。

所以我们在交流的时候，首先要进行快速的角色转换，找到对方和自己认知的“最大公约数”，英文叫做“on the same page”。然后对于交流中需要补充的知识做简单的介绍，比如系统特点，专有名词的介绍等等，避免受众一路带着问号听你说，最后对话变成了“鸡同鸭讲”。

举个例子。如果我们发现上游的订单数据有问题，那么我们可能需要找同组的人帮忙看。这时候，我们可以找组内相关的同事说，帮忙看看订单的数据是不是有问题。组内的同事对系统都是很熟悉的，不需要交代太多上下文。

如果我们发现确实是上游的数据有问题，有些字段缺失了，需要上游系统配合帮忙查找问题。这时候可以发邮件给上游系统。我给出两个邮件标题，你觉得哪个更好呢？

1.  订单数据在OrderProcessor引起异常
2.  从3月15日起，来自Kafka的订单数据，缺失了OrderingTime，OrderName字段

第一个标题，明显没有分清交流对象。OrderProcessor是自己组内项目的代码，这明显不是两个组的责任交界。数据在进入OrderProcessor之前，还有很多步骤，不能确定是上游发的数据的问题。难道你想让上游的组去看你的代码，帮你找自己代码的问题吗？

第二个标题，很清晰明确。上游数据发到Kafka，这是大家责任的交界处。时间，问题也都交代得很清楚。上游的组完全可以以此为起点，向后查找自己的问题。

简单来说，既要让对方听明白，也要让对方听到自己应该听的。交流不是应付差事，说完拉倒，也不要只顾自己说。

### 交流要带有足够的信息

我们来看一个教科书般的交流失败的例子：

A问：“订单信息数据在HDFS上有吗？”

B说：“有。”

B的回答没错，但是也没啥用。A的问题明显是想知道订单信息在HDFS的具体位置，而非只是有或者没有。B如果知道具体在那里，就应该一并告诉A；B如果不知道，也应该回答“有，但是我不知道在那里。”如果B知道谁可能会知道，那么应该一并告诉A。这样，一次交流，基本就可以结束了。

再以上面订单数据的问题举例。使用了正确的邮件标题，内容也要足够翔实。邮件内容应该包含如下信息：

1.  证明订单信息并非一直缺失这部分数据，并拿出数据，附带数据的详细来源。
2.  证明现在的订单数据并非所有的消息都缺失这部分数据，并找出缺失数据的消息ID和没有缺失数据的消息ID、时间等追踪信息，以便对方定位问题。

用数据说话，数据出处要清晰；推理条理要清晰，事情的来龙去脉要清晰。有时候写重要的邮件和文档，就像写论文一样。

### 先说重点和结论

这一条规则适用于所有场合。日常中普通的交流也是，如果带着明确的目的，那么就要先说出自己的结论和想法；如果是写邮件和文档，内容翔实的一个副作用是难免冗长。这时候应该注意，先把结论抛出来，再写细节。如果是PPT类的演讲，也是先抛出结论和成果，再去涉及详细的内容。

这样不仅可以让对方马上抓到重点，而且还可以让对方在有疑问的时候，可以带着疑问去阅读后续的细节。

## 总结

程序员的工作就像是产品。好的交流就像是包装，广告，公关和营销。有了好的产品，还要有好的包装，突出产品特点的广告，及时的公关和合适的的营销，才能赢得市场。没有这些，别人可能根本就不知道你有这么个产品，不知道这个产品能干什么，有什么特点等等。

这里再总结一下，从输入这个角度来说，交流的好处可以分为以下几点：

1.  获取更多的信息；
2.  理解公司的业务；
3.  加深对行业的理解；
4.  发现新的机会。

如果在交流中能够输出自己的内容，长期来看，给自己带来如下好处：

1.  赢得自己的声誉；
2.  树立自己的影响力；
3.  赢得同事和经理的信任，承担更大的责任。

充分的交流，并不是“就知道动嘴”，而是一个获取信息，加工信息，给出信息的过程。只有交流了，我们才能知道对方的想法，自己认为的好，可能并不是大家认为的好，自己没有想到的好处，别人可能想到了。我们在日常工作中应该多注意自己交流技巧的培养，养成喜欢和人交流的习惯。工作越久，交流在工作中的地位也就越重要。

![](https://static001.geekbang.org/resource/image/34/27/34d9e3cbbc2920518d0f37b62d42af27.jpg)

## 思考题

你是一个喜欢交流的程序员吗？你有因为擅长交流而获得什么惊喜吗？欢迎你在留言区留言，我会和你一起交流，也欢迎把这篇文章分享给你的朋友或者同事，一起讨论一下吧！