程序员必须学会沟通

我们程序员可以从解决的诸多问题中获得自豪感，比如说编写了最节省时间和空间的算法；设计了高度可扩展的架构；巧妙地为函数和变量命名；

创建的应用程序获得了五星级评分，甚至影响了全球许多人的生活。为了获得这种自豪感，我们需要战略性地规划我们的职业生涯，不断提高我们的技术技能。

为了提高我们的技术技能，我们花费大量时间和金钱来学习成为全栈和跨平台人才；每天都会在 Hackerrank 或 Leetcode 中进行 CS 理论和实践的复习；

常常购买有关最佳实践和设计模式的书籍；致力于业余项目以维护自己在 Github 上的活跃度；

通过回答 StackOverflow 上的问题来培养“声誉”——为了提升自己，我们还有很长的路要走。

所有上述这些通常都是以牺牲一个人的软技能为代价的。

软技能是人们在进行自我管理，以及与共事者（例如客户和同事）交往的过程中所使用的技能，包括领导力、情商、说服及倾听的能力、对同伴的激励，以及建立有价值的关系。

而硬技能则是指在解决问题或生产产品时所运用的高度专业化的科学知识。

通常情况下，大家都惯于认为“硬技能”掌握起来相对困难，软技能就简单易学——其实这是一种误解。实际上，如果自己未能意识到这一点并花费大量时间深入思考，软技能其实难以掌握。

沟通，或者说是将想法或信息传达给另一个人的能力，就是这样一种常被忽视的软技能。

和很多年轻的程序员一样，我也曾默认那些被指派直接与我合作的人，应该对技术原理有深刻的理解且无需我再做过多解释。

否则，他们要么不应该在科技行业工作，要么就是白痴。

许多年轻程序员认为正式的文档和流程只是官僚主义的繁文缛节，只会拖缓软件开发的进度，因此不应推行。

在传奇人物的宣传报道中，我们更是多见性格内向且多怪癖的大牛，但膜拜之余我们仍不得不承认他们大多很难合作。

程序员必须学会沟通。

首先，绝大多数编程活动都是在程序员与非程序员交互的组织内部完成的。

通常，我们必须与产品经理沟通，以充实业务需求的技术细节，以便衡量难度，评估可行性，并基于这些因素，优先考虑任务；

我们有时需要向项目经理提供评估并证明其合理性，项目经理则要确保项目符合预算要求并按计划进行；

我们需要与设计人员密切合作，以解决目标环境的局限性，识别用户在交互中缺少的流程，或发现信息设计的问题。

在与扮演这些角色的同事沟通时，我们必须时刻关注用于传达我们想法的词语或语气。

高绩效团队的一个关键因素是团队动力，如果我们在沟通中用了过激的方式而导致冲突，那么团队中就会形成隔阂以至于大家不能高效工作。

有人可能会问，为什么还有这些其他角色存在？

没有什么能阻止程序员直接与客户联络并收集需求；当瀑布模型（Waterfall Model，一种项目开发架构）比 Scrum 更受欢迎时，产品经理或许已成为过去；程序员也可以直接与 CEO 联系并使用纯逻辑来证明产品开发的可行性。

设计师也将逐渐失去存在的价值，任何编码器都可以使用自定义字体、颜色和图标甚至是矢量，而不是JPG。

我们自己能够编写单元测试的情况下，为什么还需要一个专门的测试人员团队？

真正有价值的成功产品是那些在规模不凡且需要多学科专业知识的产品。

因此，好的产品不可能靠谁独自完成。代码本身并不是一种商业行为。事实上，上述角色所涉及的工作内容往往需要花费大量的时间和精力才能完成，特别是在坚持高标准的情况下。

如果程序员以一己之力挑起所有活，那么无疑啥都做不好。即使做了也只会消耗掉原本可能专注于编写代码的时间，这才恰恰是程序员的主要任务。

另外，以这种方式否定同事的作用也是一种傲慢无知且目光短浅的行为。

产品经理为不仅仅基于我们的定位编写业务需求——这只是程序员工作的一部分——他们还通过不断研究客户行为和公司业务领域的趋势来保持产品的价值；

项目经理做的也不仅仅是证明估算的合理性——他们还会计划和调整时间表、预算，同时评估风险并管理资源分配；

设计师除了培养对艺术的良好品味外，还研究了大量心理学、人机交互、甚至神经科学，就是为了将科学发现融入公司的产品中；

测试人员不同于仅仅在开发环境中工作的单元测试，他还需要确保产品在部署到生产环境之后仍然按照预期的方式运行。

他们在消除开发人员偏见，思考“Unhappy paths”，记录错误重现的步骤，系统化测试工作流以及自动模拟用户交互方面（大多数开发人员认为这是一项苦差事）具有无可估量的价值。

程序员若跳出屏幕，外面的世界要大得多。我们应该保持谦虚，因为我们可能没有足够全面的知识来了解与我们角色不同的人的日常工作和责任。

的确，我们不能笼统地称呼那些不敲代码的人为“非技术人员”，因为他们而实际上是他们所擅长领域的技术人员，在他们的领域里我们也不过小白而已。

然而，沟通技巧的重要性或许不仅是因为需要与非编程角色互动，还在于需要与其他程序员进行沟通。

我们经常就一些抽象问题进行辩论，争先恐后地解释为什么这个好，那个棒，这个流程或框架优于另一个，以免我们的观点因带上了个人偏好而被忽视。

很多时候，工程团队都会做出一个架构决策，甚至不是因为它客观上比其他选择更好，而只是因为这个选择更有说服力。

我们也经常讨论并商定工作标准，例如版本控制工作流程和代码风格。我们喜欢互相教授高级编程技术和行业最佳实践。

最终，随着我们晋升到更高的职位，一对一地进行交流，提供反馈和管理冲突的责任变得不可避免。

其他人可能会争辩说，如果仅以“服从命令”为需求来聘请程序员，就不需要沟通技巧。

然而，即使是仅遵循项目开发指令的程序员，仍然需要通过沟通确保不可协商的要求得到充分理解。

即使是实习生和初级软件工程师，如果发现规范中存在错误，或者是在存在歧义的地方提出问题，也应该能够表达出来。

因此，沟通是程序员的核心技能。