高级开发人员的 5 种沟通方式
我刚开始做编程工作的时候，大部分时间都可以坐在笔记本电脑前写代码。我的日程安排里很少出现会议。
事实上，我开会的次数少得可怜，所以每次开会我都很高兴。这意味着我们可以聚在会议室里，通常还会吃些点心，然后就我们的产品展开讨论——有时甚至是激烈的讨论。我们一起为公司的未来发展方向制定计划。
随着时间的流逝和职业生涯的不断发展，我越来越少有机会编写代码，因为我总是被邀请参加各种会议。
我厌恶这种处境。
随着时间的推移，我意识到这是正常的。
虽然我认为我们被邀请参加的会议太多了，我们应该拒绝/委托/忽略其中很大一部分，但作为高级工程师及以上级别的工程师，我们仍然不得不花费大量时间参加会议、电话会议，或者回复聊天和电子邮件消息。
作为一名高级工程师，你的职责不仅仅是编写代码。
作为一名高级工程师，你最重要的任务之一就是沟通。
在我思考这个问题的时候，我还发现其他一些开发者也有类似的看法。
一方面，这确实是我在其他人的职业生涯中看到的现象。令人遗憾的是，管理层很少对此进行清晰的解释，这导致了一些挫败感。或许也因为沟通方式的差异很大。这一点我们将在本文中进一步探讨。
另一方面，我也发现其他博主提到了同样的事情。例如，来自“实用工程师”博客的作者Gergely Orosz 的这张图表。
他看穿了我内心深处的感受和认知。职位越高，花在软件开发上的时间就越少。
除了编写代码之外，高级工程师还会做些什么？
图片中还有另外两个类别：与其他团队合作和其他活动。
以我的经验来看，这两者主要都与某种形式的沟通有关。
因此，对于高级工程师而言，沟通的重要性几乎与软件开发不相上下；而对于初级工程师来说，清晰有效的沟通更是重中之重。当然，编写优秀软件的能力仍然必不可少，但这还远远不够。
现在让我们来看看高级工程师需要进行哪些类型的沟通，以及为什么这些沟通如此重要？
我们将要讨论的不同沟通方式有：
- 记录
- 教学
- 解释
- 给出方向
- 拒绝
记录
虽然文档在开发团队中经常被忽视，但对于可维护性而言，拥有最新且足够详细的文档至关重要。
是的，敏捷宣言指出，可工作的软件比详尽的文档更重要。但这并不意味着可以完全忽略文档。
你不必记录所有的小决策，也不必保留每次会议的日志。但架构决策应该被跟踪，代码也应该有文档记录。
后者是一个颇具争议的话题，我对此也有自己的看法。我同意那些认为代码最好是自文档化的，使用命名良好的实体并编写（单元）测试的观点。不过，我认为一些注释是有用的，甚至是必要的。同时，代码注释不应该直接说明代码的功能，而应该解释做出某些决策的原因。
作为高级工程师或资深工程师，你必须在工作的各个方面树立榜样，这一点也不例外。
如果你写作有困难，那就多加练习。观察电子邮件、备忘录和会议记录的写作方式，然后主动尝试撰写类似的内容。或者，你也可以开一个博客，看看它会把你带向何方 ;)
教学
教学的本质在于有效沟通。
有人会说，这还跟动机有关。在某些情况下的确如此，但我不想教导和指导那些需要激励的人。因此，我把动机排除在这个等式之外。
资深开发者有责任，我们有责任培养下一代开发者。别误会，我们也要保持谦逊，并向他人学习。我们背景各异，经验不同，我们可以互相学习。
然而，老年人能够而且必须多教一些东西，这是很正常的。
许多组织将教学作为一项正式职责。他们通常会指派资深开发人员作为伙伴、导师或指导者来帮助新员工。
虽然有时只是称呼不同，但我发现伙伴和导师通常来自同一团队，他们的职责是帮助新人融入团队，并提供所有必要的信息，以便他们能够胜任工作。而导师则可能来自其他领域。他们通常对受指导者所在团队的工作内容只有粗浅的了解，他们更注重提升技能，帮助受指导者达到更高的水平，而不是帮助他们融入特定团队。
如果你有机会接受导师的指导，一定要抓住机会，这能为你实现目标提供正确的指导！
然而，即使没有正式的制度，教学活动也能而且将会进行。
你将通过代码审查进行教学——希望能够举出好的例子——你可能会进行一些知识分享演示，或者只是与其他人聊天。
不要以为人们只会就技术问题来找你。我经常被问到职业建议，或者如何应对某些人、某些情况。
毕竟，正如我们所见，职级越高，需要处理的非技术性问题就越多，所以其他人也会就这些问题向你寻求建议，这并不奇怪。
解释
当你教学时，你主要是在教育与你水平相近或略低的同龄人，并且有明确的理由。其他人应该能够完成你所教授的相同活动。
但有些情况下，你需要以不同的方式、出于不同的目的来分享你的知识。
有时候，你需要分享你的知识，你需要解释一些事情，但不需要教别人钓鱼。你只需要说明为什么某个方案是好的，或者最终是坏的。
你必须与技术人员和非技术人员合作，并且你必须能够清晰地表达你的观点，不是基于你自己的知识水平，而是基于你的合作伙伴的知识和背景。
最重要的一点是，你必须能够使用同事期望的细致程度。你必须用对方能够理解的方式进行解释，并且要让他觉得有趣，愿意听下去。
当你们争论选择哪种数据库技术时，你的队友会非常关心如何进行查询，而你的工程经理肯定会对一些技术细节感兴趣，你的业务伙伴则不会关心这些，而是会关心哪种技术会对客户和成本产生什么影响。
解释的时候，想想对方重视的是什么，然后重点放在这些方面。
给出方向
另一种略有不同的沟通方式是下达指令。优秀的管理者不想成为房间里最聪明的人，也不想仅仅依靠自己的知识、研究和直觉来做决定。
他想获得指导和建议。作为一名资深开发人员，你应该能够提供这些指导，无论是口头还是书面形式。清晰地表达你的主要观点，能够深入探讨优缺点，并且敢于指出存在的问题、你不了解的地方，或者你还没有时间研究的地方。
分享未知信息与分享已知信息至少同等重要。或许其他人了解这些未知信息，即便不了解，团队也能知道哪些方面需要研究，下一步应该重点关注哪些方面。
与此同时，我们也不要忘记，我们不可能无所不知，也不可能掌握所有细节。然而，许多人却试图把自己塑造成一个无所不知的人。
诚实一点，坦诚分享你不知道的事情，这甚至会提高你的信誉度。
拒绝
作为一名资深开发人员，有时你需要做的不仅仅是分享你的观点。毕竟，你是专家。如果你确信某件事行不通；如果你确信某件事不道德；如果你确信你的管理层或业务部门正在走一条灾难性的道路，你就必须站出来说“不”。
不，那样不行。不行，那样做肯定行不通。再说一遍你的理由，告诉他们你不愿意那样做。
这种勇气蕴含着两层含义。
这张牌你很少能用上。如果你是个自认为永远正确的人，最好还是别用。如果你是个从不妥协的人，也别用。
但如果你是一个讲道理的人，请记住这一点。
如果你准备说“不”，那就意味着你应该真正说到做到。你应该做好站起来离开的准备。
如果双方都无法被说服，你只有两个选择：要么听从指示去做，但你并不相信；要么站起来离开。
你知道哪个才是正确的选择。
如果你想成为一个能够说“不”的人，你必须足够优秀，才能始终给自己留有多种选择。
总之，别忘了，即使你们意见不合，决定离开，但这仅仅是生意上的事。这类冲突不应涉及私人恩怨，因此其后果也不应影响到私人关系。
理论上是这样。不过，我们还是应该记住这一点。
结论
资深开发人员的工作不仅仅是编写代码。即使难以接受，但事实是，职位越高，你的职责就越少与编写代码相关。
职业生涯越深入，即使是作为一名普通员工，你也需要进行越多的沟通，包括口头和书面沟通。沟通的形式多种多样——我指的并非前面提到的输出渠道。有时，我们需要撰写文档；有时，我们需要指导他人，将知识传承下去；有时，只需分享要点，但要确保信息传达给从事不同工作、关注点各异的人。
此外，你的专业程度越高，懂得越多，就越需要你给出指导，甚至在必要时提高音量说“不”。
在以后的文章中，我们将逐一分析这些文档的各种形式，我也会分享一些提高每种文档编写水平的方法。
更深层次的联系
如果您喜欢这篇文章，请
文章来源：https://dev.to/sandordargo/5-types-of-communication-a-senior-developer-does-19o1