软件工程师的沟通之痛

程序员的沟通之痛

软件工程师的沟通之痛

去年底看到陈皓（酷壳博主）写了篇很好的文章《技术人员的发展之路》，里面提及职业发展的一定阶段，也许你会碰上一些复杂的人和事，这种情况下他写道：

这个时候再也不是 talk is cheap, show me the code! 而是，code is cheap, talk is the matter!

这里的 talk 其实就是沟通，近年来发现沟通越发成为一件重要的事。在近期的工作中也会观察到一些沟通问题，比如跨团队开会沟通时发生的一些分歧与争论。作为程序员的我感觉沟通一直是一个痛点，所以近年来一直在思考关于沟通的问题，下面就写写我的观察与思考吧。

木讷与沉默

这两个名词似乎已变成了程序员的标签，它们形象地体现了程序员在沟通中的表现。在程序员的世界里，沟通可能包括：与产品经理沟通需求、与同行交流技术、与外行交谈，还有与同事分享工作与生活的趣闻等。

有些程序员在分享趣闻与谈需求或技术时的表现大相径庭，刚才还是一个开朗的小伙突然就变得沉默不语了。沉默有时是不想说，特别在沟通需求时，程序员心里想着：与其扯那么多，哥代码都写完了。不就是一个小功能吗，默默无言，笑而不语的就接下了，想着赶快结束去写代码了。

程序员写出的代码本应该是公司的资产，但现实是代码这东西是同时带有资产和负债双属性的。Linus 写的 Linux 或者 @antirez 贡献的 Redis 里面包含的代码是极好的资产，但大部分我们沟通不充分的需求，最后基于此写出来的代码都是负债大于资产。最后，往往是出来混都是要还的，不是自己还就是别人来还。

程序员可能会争辩道，与人沟通本来就不是我们所擅长的，我们并不是因为热爱跟别人聊天才做软件开发这一行的。这个言论很有迷惑性，我早年一度都是这么认为的。当年毕业去找工作，外企如日中天，去了当时心中的很牛的 IBM 面试。面试过程中大部分的交谈过程我都记不清了，就一个问题至今很清晰。面试经理问我：你是喜欢多些跟人打交道呢，还是跟电脑打交道？当时的我毫不犹豫的回答喜欢跟电脑打交道，喜欢编程写代码，而且自觉我也不擅长和人打交道。

然后，我就被淘汰了。后来我才明白了，其实当时的这类外企挂着招软件工程师的名义，实际需要的更多是具有技术背景和理解的售前技术支持，因为在国内它们基本就没有一个真正的研发中心。如今我认为，即便你仅仅只喜欢写代码，那么和人的沟通能力依然是你跨不过去的瓶颈。写代码本身就是一种沟通，一种书面沟通。

程序写出来是给人看的，附带能在机器上运行。
--《计算机程序的结构与解释》

沟通从来都是个问题，书面沟通同样困难。

争论与无奈

程序员产生争论的地方多半都在和同行的沟通中，想必很多人都和同行有过关于技术方案的争论。我自己就曾在过去多年的工作中和同事有过技术方案之争，得到的教训可以建议给技术经理（主管）们：不要让两个都觉得自己很牛的程序员去同时设计一个技术方案。不巧，你已经这么干了并得到了两个不同的方案，那么记住，就别再犯下一个错：让他们拿各自的方案去 PK。

既然分歧已经产生了，为了避免无谓的争论，该怎么解决呢？

以理服人

首先，把握一个度，对事不对人，切勿意气用事。有些技术人之间的分歧点是非常诡异的，这可能和技术人自身的洁癖、口味和偏好有关。比如：大小写啦、命名规则啦、大括号要不要独立一行啦、驼峰还是下划线啦、Tab 还是空格啦，这些都能产生分歧。一旦处女座心态爆发，很可能一发不可收拾。

如果你因为“该怎么做某事或做某事的一些形式问题”与他人产生分歧，那么在很多情况下，你最好先确定分歧点是否值得你去拼命维护。这时，你需要判断一个技术的「理」在什么地方，这个「理」是你值得拼命坚守的底线不，用这个「理」能否说服对方吗？

我所理解的技术的「理」包括：先进性、可验证性、适配性（和团队）、时效性、成本和收益。另外一些不合适的「理」包括：风格、口味、统一、政治。

不过有时候，有理也不代表就能搞定分歧，达成一致。林子大了，不讲理的人也是有的，那么下一步。

以德服人

分歧进入用「理」都无法搞定时，那就是应了那句古词：“剪不断，理还乱。”。这时继续理下去，不过都是互相耍混了。

「理」是一个客观需要双方去认可的存在，越理越乱说明双方至少没有这种客观一致性的基础，那就找一个主观的人来做裁决吧。

德，谓之德高望重，是否有一个双方都认可的人来做裁决，这个人通常就是所谓经验丰富的老司机了，比如架构师之类的。这类主观裁决也不一定能让双方都满意，有时实力相当的技术人也容易产生类似文人相轻的状况。不过看在老司机的德面上，也能勉强达成一致。

老司机裁决最好站在他所认同的「理」的这个客观存在上，这是最好的，不过这也取决于老司机的工作素养和价值观了。

以力服人

最差的状况就会走到这一步，特别在跨大部门的沟通中。技术方案无法达成一致，也没有一个跨两个部门的有德之人可以转圜化解，就会升级到这个地步。

最后就是靠粗暴的权力来裁决，看双方部门老大或老大的老大，看谁更有力或给力。一般来说非关键利益之争实在没有必要走到这一步了。

认识与改变

做出改变的第一步是要能认识到，否则改变不可能发生。程序员会认识到沟通很重要，有时会比写代码更重要吗？程序员著名网站之一 StackOverflow 的两位创始人 Jeff Atwood 和 Joel Spolsky 都对此有正面的认识和见解。

Jeff 说：

成为一名杰出的程序员其实跟写代码没有太大关系。
做程序员确实需要一些技术能力，当然还要有坚韧不拔的精神。
但除此之外，更重要的还是要有良好的沟通技巧。

Jole 的观点：

勉强过得去的程序员跟杰出程序员的不同之处，不在于他们掌握了多少种编程语言，也不在于他们谁更擅长 Python 或 Java。
真正关键的是，他们能不能把他们的想法表达清楚，杰出的程序员通过说服别人来达成协作。
通过清晰的注释和技术文档，他们让其他程序员能够读懂他们的代码，这也意味着其他程序员能够重用他们的代码，而不必重新写过。
要不然，他们代码的价值就大打折扣了。

按照程序员解决技术问题的习惯，就是对大问题作拆解，我们也对沟通作下拆解，它包括三个方面：

内容
方式
风格

从内容看，即使你想沟通的本质是同一样东西或事情，但你需要针对不同的人准备不同的内容。比如程序员和内行与外行谈同一个技术方案，内容就是不同的。这里需要发挥同理性和换位思考的能力。Paul Graham 曾在他的书《黑客与画家》中写到：

判断一个程序员是否具备“换位思考”的能力有一个好方法，那就是看他怎样向没有技术背景的人解释技术问题。

换位思考本质上就是沟通技巧中的一种。

从方式看，沟通其实不局限于面对面的谈话，面对面交谈是一种形式，书面写作又是另外一种形式，连写代码本身都是在和未来的自己或某个你尚未谋面的程序员沟通。对于程序员确实有很多都不擅长面对面的沟通形式。

面对面沟通的场景是很复杂的，因为这种沟通中交流传递的载体不仅仅是言语本身。你的眼神、姿态、行为、语气、语调高低，甚至一种很虚幻的所谓气场，都在传递着各种不同的信息。而大部分人都不具备这种同时控制好这么多传递渠道的能力，我们经常通俗的说是缺乏控场能力，这里面隐含着对你其他能力的要求，比如：机变、思维的活跃度与变化等。

从风格看，交谈风格和写作风格可以是完全不同甚至对立的。比如：「小道消息」的作者 Fenng（冯大辉）的文字风格很多时候给人的感觉是简短、尖锐和犀利的，但据说（来自知乎评论）其私下的面谈风格完全与之不同。

因而，沟通之难在于清晰的传递内容和观点。当你要向其他人详细解释某样东西的时候，你会惊讶地发现你有多无知，于是，你不得不开始一个全新的探索过程。这一点可以从两个方面来体会：

你只需要尝试写点你自认为已经熟悉掌握的技术，并交给读者去阅读与评价。
如果你的公司晋升采用一种述职答辩的方式（现在很多互联网公司采用），你就会体会到这一点。

我每次写完一篇技术文章，都会发现一些漏洞或者 bug，主要出现在我总觉得我想表达的东西没有足够清晰或是有歧义，或漏了一些。但文字不像代码，你搞错了一些东西，漏了几个字符，编译器或运行环境会给你扔出几个警告或错误，或者干脆就不让你运行。所以也很难像写代码一样去反复重构和优化文字。

...

江山易改，本性难易，有时候我们做不到就在于这一点。

如何更好的沟通对我也是一个很难的挑战。不过若能通过本文，让你了解到这种处境，即使还无法做出任何改变，但仅仅是了解了这个事实，也可能会让你感受好些。

写点文字，画点画儿，记录成长瞬间。
微信公众号「瞬息之间」，既然遇见，不如一起成长。
软件工程师的沟通之痛

14楼一笑amp;: 我觉得楼主的文章，每个不善于沟通的程序员都应该读一读，很有指导性。

13楼thirking: 反思一下，，，

12楼vbfool: 说真的，大部分的代码，远比他们说的话清晰明白一些。，当然我也遇到很多很能说的，不过他们的代码基本都是一塌糊涂。

11楼上位者的怜悯: 一把辛酸泪。，，至今不敢看陌生的女孩纸，更别提说话搭讪。，，眼睁睁在奔三的年龄，还没有女朋友。，，高白瘦，五官端正，善良正直，收入尚可，手特别漂亮，有人找过我做手模。，有意的小姑凉可以私信我。

10楼吴瑞祥: 没有说到重点.，不会沟通和是不是程序员完全没有任何关系.，只看自己愿不愿意去沟通.，我敢说大部分说不好沟通的情况.都是2个人里的某个人不愿意沟通造成的.，当然不排除有人没有quot;好好说话quot;的能力

9楼xuanbg: 对程序员来说，写出来的代码是负债，对业务的理解和知识的运用技巧才是资产！所以写代码需谨慎，能不写代码解决问题就不要写代码。，，但可悲的是：程序员必须多写代码，才能做到少写代码。。。

8楼Sunday*: 我觉得木纳是个人的性格而已，不是程序员的标签。，反正我身边的程序员都是很逗比，不乏沟通的技巧，甚至是有着个人魅力。，沟通是一项技能，和生活工作息息相关，在群体社会必须会的。，文中还提到一点技术分歧，我觉得应该就技术的优越做好分析开会研究，权衡利弊取其重要的，定好的技术就无条件服从。，技术无绝对对错，只在有适应场景，同理也适用于生活中的各样问题。

7楼ashowlyj: 程序员要的就是木讷与沉默，太会说的写不好代码

6楼冲杀: 对需求的沟通把握不好会得罪人的，另外就现在中国的各个民营企业管理阶层而言，下面对需求的沟通太激烈了她们会认为你们吵架！如果一个需求太烂了，把实际的缺点什么的不足什么的指出来，又会认为你是在找接口推诿工作！，一般来说，拿到任务不开腔，默默就做出来，不管好坏做出来！这种员工最讨喜，老板也喜欢！！，这就是现状！

5楼DeeRoad: 很赞同，沟通能力确实是程序员的弱项。，与人沟通比与机器沟通难多了，因为机器是完全客观的，你的代码能运行就是对的；但是与人沟通时中间夹杂了太多主管的因素。

4楼婷风: 哈哈哈哈，很有道理

3楼GIS之家: 沟通真的是一门艺术

2楼zhangkailun: 赞楼主

1楼小柳爱吃肉: 自己也在学习,沟通