作者丨Jordan Cutler

编译丨诺亚

出品 | 51CTO技术栈（微信号：blog51cto）

作为一名高级软件工程师，我在迄今为止的职业生涯中领悟到了五大教训。可以说，这五个教训塑造了今天的我。当然，这些教训仅仅基于我个人的经验。您可能有过不同的经历，我的分享只是为了避免一部分人重蹈我的覆辙！

1.教训1：提出解决方法，而不单单是问题

当时我在一个团队中担任高级工程师职务，我们团队依赖于另外两个兄弟团队提供的数据支持。

问题来了：我们从其中一个兄弟团队获取的数据响应速度极为缓慢，由于向他们请求数据需要500毫秒至4秒的时间，这就导致了客户看到的加载时间长达3秒甚至更久。

那个团队也意识到了这个问题的存在，但他们正忙于应对各种优先级相当的竞争任务。更糟的是，我没有使情况得到任何改善。

我在团队回顾会议和团队沟通渠道中多次提及这一问题。单就指出问题而言，这并不是什么坏事。但我的态度传达出的信息是：“这是你们团队亟需解决的一个严重问题”，而不是“我们能否共同合作找出解决方案？”这样的协作态度。

直到我的经理给出反馈后，我才意识到我当时这么做的问题。

我本可以安排与该团队的一位负责人进行一对一交流，共同制定解决问题的计划，而不是仅仅提出问题，让任何人因问题而感到沮丧。尽管我的初衷是为了改进我们团队及客户体验，但我本可以在解决问题的过程中采取一种方式，让我们整个团队都能在这个过程中感受到积极正面的影响。

比如像这样：端点的性能问导致客户的加载时间超过 3 秒。我很乐意与您合作共同解决这个问题。我能提供什么帮助吗？

2.教训2：干净代码并不是终极目标

作为一名初级工程师，我在代码审查时极其严苛，坚决不让任何在我看来“不够美观”的代码进入生产环境。结果这让我的一位同事对我相当不满。

此事最终被上报给了我的上级经理，我们三人之间进行了一次对话并解决了问题，但这并非是一个令人愉快的局面。而且在这次事件之后，我并没有吸取应有的教训。

虽然我稍微有所收敛，但随后又因为我的评论意见，与另一位同事产生了分歧。

我们在GitHub上进行了多轮来回评论，双方关系因此变得紧张。

我当时询问了我的上级应该怎么办，他反问我：“如果你放弃一半的评论意见会怎样？每一条评论都值得争论吗？”

我的回答是：“代码可能会稍微不那么整洁。”

现在仔细想想：为了追求“代码整洁”，是否值得牺牲你与同事之间的和谐关系呢？答案显然是否定的。

于是，我开始对评论意见变得宽松。我减少了评论次数，明确区分哪些是小瑕疵，并且大部分时候我都选择批准，除非我有严重的疑虑或担忧。

结果如何呢？我的关于小瑕疵的评论更容易被接受。我和同事之间建立了信任关系。他们不再感觉受到攻击，而是觉得我们是在共同合作。

保持代码整洁并非最终目的，协作才是。

3.教训3：团队产出大于个人产出

我有一个坏习惯，就是在从事主要项目时容易被我能做的代码改进工作分散注意力。当然，适度地进行这种改进是可以接受的，毕竟在前进的过程中优化事物是有必要的。

但我会承担起一些完整的改进计划，比如对于JavaScript代码中的某些部分感到不满意，进而决定将40多个文件转换为TypeScript，并提交审查。  

幸运的是，至少我所做的事情通常都是组织内部已经达成共识的改进计划。然而，我没有充分认识到更大的全局性问题。我提交审查的所有代码不仅仅是占用了我的时间，同时也占用了队友们审查的时间，并且对我们团队来说，合并和部署未预先规划的工作意味着额外的风险。

我当时本可以专注于推动团队业务发展，例如：

* 向我的上级询问他们的首要关注点，并集中精力解决这些问题；

* 寻找方法协助团队完成任务； 

* 处理客户服务团队转交的bug报告。

那时，我过于专注于自己想做的事情，而忽视了团队的高级别目标以及如何推动这些目标向前发展。

有几件事让我意识到这一点。我的一名指导对象，另一位高级工程师，在短短6个月内就获得了晋升，原因就在于他具有这样的专注力。

他能够以极快的速度完成预期的工作，然后利用剩余时间来解决团队及其合作伙伴（如客户服务团队）面临的最大问题。

专注于团队成果，而非个人成果。

4.教训4：适应你的老板

尽管我们都希望能有一份与上司相处的万能指南，但实际上唯一有效的指南是那些教你如何适应不同上司的方法。

在我的职业生涯中，我曾有过五位直属上司，每次都需要针对具体情况做出适应。

举例来说，当涉及到晋升或职业发展规划时，有些上司会非常主动，明确告诉你需要做什么。而另一些上司可能由于工作繁忙，无法给予你那样的关注。在这种情况下，我不得不主动为自己制定一份计划，并寻求反馈意见。

5.教训5：影响力不在于措辞

长期以来，我一直阅读关于影响力和说服力的书籍，试图找出如何措辞以增强自己的影响力。

我听到过这样的建议：“让人们先答应一个小要求，这样他们在面对你的下一个请求时就已经处于‘愿意答应’的心理状态。”或者，“使用‘你是否愿意考虑’而不是‘你能否’，因为人们希望他人认同自己思想开明，他们会把‘愿意考虑’与开放心态联系起来。”

请注意，这些技巧确实有所帮助，并且在适当的情况下我会运用它们。但在影响力方面，它们并不是最有效的手段。

最具影响力的举动其实是建立人际关系。

我敢打赌，你不需要绞尽脑汁去思考如何向认识多年的好友提出请求，这是因为你们之间有着深厚的关系，朋友了解你的意图并且愿意提供帮助。

当我意识到这一点后，我把重心从“措辞”转移到了建立关系上。我开始与队友定期进行一对一交流，更多地赞扬他们的优秀工作，并抓住更多机会去支持他们。正是这种方式帮助我提升了影响力。

重点在于建立充满信任的人际关系——这样一来，你甚至无需担心如何去提出请求。

6.小结

长话短说，简单总结一下。

教训1：提出解决方案，而不是问题。重点展示你如何支持需要帮助的团队，即使只是作为顾问。

教训2：整洁的代码并不是最终目标。与团队有效协作比确保每一行代码尽可能干净更重要。

教训3：团队成果 > 个人成果。你花时间做的事情应该与能给团队带来最大影响的事情直接相关。

教训4：适应你的上级。每个老板的领导风格都会有所不同。了解如何适应其风格和目标，以实现最佳的集体成果。

教训5：影响力与措辞无关。专注于建立以信任为基础的关系。这比你如何选择你的表达技巧更重要。

参考链接：

https://careercutler.substack.com/p/5-lessons-i-learned-the-hard-way