一位拥有 8 年经验的软件工程师的建议

我的职业发展历程

在深入探讨主题之前，先介绍一下我的职业生涯发展历程：

我开始在一家初创公司（该公司很快就扩大规模）担任实习生 3 个月。
之后，我进行了一整年的勤工俭学，其中3个月在学校，9个月在工作。
随后，我被聘为全职软件工程师，并担任该职位三年半。
在技术职业阶梯制度推出后不久，我就晋升为高级软件工程师。我保持这个头衔三年，直到我离开公司，那时技术团队大约有200人。
我加入了一家拥有数千名技术员工的公司，担任软件工程师2。尽管在第二家公司职位有所下降（参见《大型科技公司招聘保守——但原因何在？》），但我一直努力保持与之前相同的职责。

一开始，我是前端团队的一员。技术部门分为后端开发人员和前端开发人员。当时，我们只有不到30名工程师。一年后，新任首席技术官上任，他引入了一个基于功能团队的组织架构：Spotify 模式。虽然一开始有些摩擦（人们不喜欢改变），但这次重组最终无疑带来了好处。

我在同一个功能团队待了五年多。从项目成立之初我就在那儿，所以这些年来，我一直担任着这个项目的技术顾问。最终，我加入了另一个团队，在那里一直工作到一年后离开，去开启一段全新的冒险。

好了，背景介绍就到这里。希望您喜欢阅读接下来的内容，并希望以下建议能够帮助您的职业发展！

我希望早点开始做的事情

写工作日志

工作日志是一份记录你已完成任务的文档。任务的粒度和类型并不重要，只要你记录下自己所做的一切就行。

您可以按自己想要的频率填写此文档。我建议每周填写一次。一周内完成的任务到周五仍然清晰可见，这样您就不用费力地把它们记下来了。

为什么这份工作日志如此重要？原因有二：

提醒自己过去6到12个月所做的一切。这在绩效评估中非常有用，可以向你的经理展示你的成就，以及你为什么值得加薪或晋升。
记录你职业生涯中参与的项目、重要职责以及关键数据（例如，将关键服务的延迟降低了 X%）。无论何时你想在招聘市场闯荡，这都是完善简历的绝佳工具。

我在离开第一家公司大约两年前开始写工作日志。所以，在过去的8.5年里，我的工作日志只包含了3年的数据（中间有一些空白）。2021年末，当我需要写简历时，我不得不依靠记忆来回忆职业生涯前五年做了什么。至少可以说，我花了一些时间才记起所有有价值的东西，而且我肯定有些东西我已经忘记了。

如果需要，您可以使用工作日志模板（这里有一个示例）。就我个人而言，前两年我一直在使用 Microsoft Notes，后来我换成了 Google Docs，它有项目符号（一年中每个月一个列表）。

离开舒适区

这是学习并成为更优秀开发者的最佳途径。舒适区是指你感到舒适的工作范围和环境。它包括你已经认识并每天与之共事的队友、你多年来一直参与的项目、你一直承担的责任等等。

但为什么有人会建议你离开这个美好的环境呢？因为这个环境并不适合进化。

当然，如果你保持这种状态，你就会成为一个高效的人。你已经知道该和谁讨论某个具体问题，以及代码库中的哪个文件需要修改。但是，还有什么比一个高效的人更好呢？几个高效的人！

一旦你对某个特定主题感到满意，你应该寻找：

指导人们，使他们能够熟悉这个话题。
在你的舒适区之外寻找一些新的事情去做。

指导是高级职位应尽的职责之一。这是帮助我们的同事快速提高效率的好方法。你将成为力量的倍增器。

至于要做的事情，可以是任何事情。以下是一份非详尽的清单，希望能给你一些启发：

为您以前从未有机会接触的团队或组织的项目做出贡献，例如，因为它总是分配给同一个人（处于他们的舒适区）。
撰写关于你熟悉主题的文档。目标是分享你的知识，并间接地指导他人，使他们能够比你更快地掌握这些知识。此外，写作是一项值得学习和提升的技能，无论是撰写文档、电子邮件、即时消息、RFC（征求意见稿）、博客文章等等。
自愿参与跨团队项目。你甚至可以在这些项目中担任领导职务，一举两得。
注意改进工具、监控或团队/组织流程。
参加公司组织的聚会。
加入公司的社区/公会，从事组织级、跨团队的项目。
通过进行技术面试和/或检查候选人的家庭练习来帮助招聘团队。

目标是学习新知识。绩效评估可以帮助你明确走出舒适区后应该做什么以及如何去做。但你不必等到那一刻才采取行动。你可以随时行动，只要你的经理知道。例如，你可以在一对一会议中谈论这件事。经理的核心目标之一是帮助你在职业发展中取得进步，所以我强烈建议你在离开舒适区之前与他们沟通。

有些主题可能你并不真正感兴趣。就我而言，很长一段时间以来，我并不想学习任何与机器学习和数据分析相关的知识。但是，我的好奇心和求知欲最终引领我走上了这些主题的道路。尽管我没有机会参与基于这些领域的公司项目，但我很高兴我学习了这些主题。与同行进行有意义的对话非常棒，它甚至可以帮助我找到没有这些知识就无法获得的想法。

如果你想在事业上有所进步，我强烈建议你走出舒适区，抓住一切机会学习新事物。我相信这条建议也适用于个人生活！

对其他团队和项目保持好奇心

尽管您不必承担额外的责任，但这一点与前一个类似。

很长一段时间以来，我并不关心团队范围之外的团队和项目。我们的产品与其他团队的服务有一些依赖关系，但只要我们和他们之间的 API 定义清晰，我们就不需要了解他们的任何服务。

我们唯一需要打开盒子看看运作情况的时候，就是我们必须为这些项目做贡献的时候。由于我们被分成功能团队，如果公司其他项目需要修改，就必须自己动手。每个功能团队都有自己的路线图，所以我们不能要求其他团队替我们做这项工作。虽然一开始我们进展缓慢，但在另一个团队的帮助下，我们为他们的项目做贡献时效率逐渐提高。

但是，对于那些我们没有直接接触的服务，我完全不知道它们是如何运作的，也不知道它们在系统中的具体作用是什么。直到几年后，我加入值班团队，才真正开始审视公司的所有服务。当我最终对公司有了全面的了解时，感觉棒极了：

当事情出错时，我可以更好地了解罪魁祸首是什么。
我知道我们为什么需要那个特定的服务，或者为什么选择那个数据存储。
经过多年为公司创造的价值，最终将一切拼凑在一起，给人一种“哦，现在我明白了”的奇妙感觉。

如果可以的话，看看公司里的其他项目和团队。阅读他们的内部wiki页面，参与他们的演示，阅读他们的公开文档。这些你可以时不时地做，不必持续努力。额外福利：如果你能画个图，并写一些关于“全貌”的文档，那就去做吧。组织里的很多人很可能会因此感谢你！

请注意，与之前关于舒适区的建议相比，你无需在这里投入任何精力。你只需要保持好奇心，阅读其他团队的文档并提出问题。你可能会在此过程中遇到其他团队的人，并发现你真正想参与的项目。

加入值班团队

这一点可能会引起争议，甚至可能在你的公司根本无法实现。当然，只有当你的公司拥有健康的值班环境时，你才应该考虑这个建议（参见软件工程师的值班薪酬）。

值班团队由愿意在工作时间（例如夜间、周末和银行假日）出现问题时进行干预的人员组成。您的公司可能拥有专门的 SRE（站点可靠性工程师）团队，并且/或者您的团队可能不负责DevOps 工作。

但是，如果您有机会加入值班团队，无论是为您负责的产品，还是为整个公司（取决于公司规模），我都建议您这样做。

我认为加入这个团队有以下优势：

您将了解到很多有关使公司蓬勃发展的产品和服务的“幕后”信息。
每当发生不好的事情时，尤其是在晚上，您都会感受到责任的重担，因此您会对您的同事更加同情。
您会对公司产生更强的归属感，因为您会投入更多的时间来确保产品和服务能够按照客户的预期运行。

再次强调，在承担这些责任之前，需要一个健康的值班环境。

在我的第一家公司，我大约在离职前两个月加入了值班团队（负责所有服务）。真希望自己能早点加入，因为在这几个月里我学到了很多东西，而且这份额外的职责也让我得到了很好的回报。

在我的第二家公司，也就是现在的公司，我第一天上班两三个月后就加入了值班团队（负责单一产品的服务）。目前，我只在工作时间参与，但最终我将能够在晚上和周末回复客服。

更换团队

我认为你会转投其他球队有三个原因：

您对目前的职位感到太舒服了，并且想要走出自己的舒适区。
您不太喜欢团队的项目/范围，并且希望从事您更喜欢的项目。
您与同事和/或经理的关系已经恶化，您想在仍然留在公司的同时呼吸一些新鲜空气。

如果您发现自己处于上述情况之一，那么我鼓励您考虑加入一个新团队，而不是辞职并寻找一家新公司。

换公司是件很累人的事，而且你可能会失去一些你真正珍惜的东西，比如同事、工程文化或员工福利。

我认为团队跳跃很棒，原因如下：

新团队的组织可能会有所不同（仪式、合作方式），因此您可以在该领域获得更多经验。
您可以带来从以前的团队学到的积极变化（改进代码审查流程、工具、库、仪式），从而成为公司良好实践的倡导者。
当您的新队友必须从事您之前团队的项目时，您可以为他们提供帮助（即知识有效地从一个团队传播到另一个团队）。
你可以学习新的工具、语言、库、架构以及解决问题的方法。换句话说，成为一名更优秀的开发人员。
如果您的变动是由于前面提到的第 2 或第 3 个原因，那么您有可能在更好的条件下工作。

在离开第一家公司的前一年，我决定跳槽到另一家团队。当时有几个团队邀请我加入，如果可以拆分成多个团队，我很乐意加入他们。

加入新团队后，我感觉自己的高级头衔不再那么重要了。我必须学习新的代码库、工具和实践。当然，我的软技能和业务/产品知识得以保留，但我的技术技能却受到了冲击。学习新知识固然很好，但我不再是团队的技术负责人了。不过，每当团队需要为我之前团队的项目做出贡献时，我都能以更高效的方式帮助他们。随着时间的推移，“不配拥有这个头衔”的感觉逐渐消失，随着技能的积累，我变得更加优秀。

话虽如此，我认为换团队不应该太频繁。我在第一家公司待了五年多，然后又换了一家新公司一年，最终因为一些与新团队无关的原因离开了这家公司。

如果你觉得自己的情况符合这三个原因之一，我建议你考虑换工作，但前提是你在目前的团队至少待满一年。我认为一年的时间足以让你感觉自己是否适合现在的团队。如果你等不了一年，那就意味着情况非常紧急，我建议你联系你的经理，以及/或者他们的经理来处理紧急事宜。

撰写博客文章

这一项应该直接写“写作”，但感觉太短了。写作是开发人员应该具备的最重要的技能之一。我们的很多日常工作都涉及写作：代码、消息、电子邮件、文档、RFC、会议记录、事件事后分析等等。

写作是与人沟通的最佳异步方式之一。他们可以在任何方便的时候阅读你的信息，不会在工作中被打断，从而可以专注于工作。当然，在某些情况下，同步沟通是更好的沟通方式：例如视频通话、面对面会议，以处理一些紧急情况或消除歧义和误解。但根据我的经验，开发人员在日常工作中更多地接触写作而不是交谈。

撰写博客文章很有趣，原因如下：

熟能生巧。提升技能的唯一方法就是练习。如果你不确定自己做得对不对，可以向你认为做得好的人寻求帮助，让他们在这方面给予你指导。你也可以阅读相关的文档和博客文章。话虽如此，最重要的是开始练习，即使你的第一篇文章存在一些缺陷。
它迫使你去了解你正在谈论的主题。这是一种非常好的学习方式，通过比平常更深入地研究某个特定主题。
它能打造你的个人品牌。越多人对你的博客文章感兴趣，你的粉丝就越多，你的影响力也就越大。

您可以在个人博客或公司博客上撰写文章。为公司博客撰写文章在初期是很好的，因为它已经拥有一定的读者和关注者群体。但是，您在讨论主题上的自由度会较低，因为这是公司的选择。

不要指望第一篇博文就能火起来。要成为有影响力的人需要很长时间。你甚至可能永远都达不到那个程度，这没关系。你应该为自己而写，提升你的写作技巧，并与社区分享你的发现。你不应该在意有多少点赞或粉丝。没错，获得这类关注确实能极大地鼓舞士气，但你的目标不应该是增加这些数字。你的目标应该始终是提高你的写作水平并分享知识。

我在我的第一家公司的工程博客上发表了一篇文章，开启了我的这段旅程：在 Web 浏览器中调度函数的最准确方法。这篇文章甚至在JavaScript Weekly 新闻简报中被提及，这感觉太棒了。

之后，在2021年3月，我开始在Dev.to上写博客，并且会不时地更新。我也在HackerNoon 上发过一篇文章，但我不太喜欢他们对标题的编辑，而且我觉得 Dev.to 会成为我的主要博客平台，至少目前是这样。

我希望自己能以不同的方式做事

向团队介绍新事物时要小心

随着你的资历越来越深，这一点尤其重要，尽管即使是初级员工也应该有能力向团队引入新事物，无论是库、语言、范式、合作方式等等。作为初级员工，你会更容易受到团队中资深员工的挑战。然而，你的资历越高，就越容易说服人们，尤其是初级员工，加入你的团队。

回到我的第一家公司，在跳槽到另一支团队的几个月前，我正处于一个可以提出……对代码库进行雄心勃勃的修改的位置。那时我已经学习了几年函数式编程范式，并且确信它的优势。

在过去的几个月里，我向包括我自己在内的两个团队介绍了函数式编程的概念。需要说明的是，这些演示是在我对代码库进行重大修改之前进行的。

我以为这些培训课程足以说服人们采用这种新模式。当时确实如此：人们纷纷点头表示赞同。他们理解了这些新概念、利弊，以及我们可以利用哪些方法改进项目。

在这些演示之后，我们看到了一个机会：

当时正值夏季初期，所以接下来的几个月里商业活动将会相当低迷。
在上半年，我们在最古老的系统之一中遇到了一些错误，不得不使用肮脏的解决方法。
我们可以使用函数式概念和 TypeScript（又名 TS）的类型，大幅提升该系统的可测试性和开发者体验。该旧系统最初是在 TS 的早期版本上开发的，当时并没有提供出色的类型特性。

换句话说，这是进行重构的绝佳时机！我向团队展示了一个概念验证，使用 TS 进行函数式和类型级编程，极大地改进了该系统。我们都对它的优势深信不疑，并决定进一步推进，打造一个可用于生产的版本。我负责创建任务、规划可以并行完成的任务等等。我定期在 Slack 频道发布更新，以便利益相关者跟踪进度。

我把系统的 v2 版本开发成了我们自己代码库中的一个库，使其成为一个独立的模块，这样就可以测试所有我们能想到的边界情况，而且由于副作用最终得到了控制，我们还进行了单元测试。尽管引入了许多新概念、新函数和代码更改，但大家都很满意。我在代码审查期间也获得了批准。

我深受fp-ts 库的启发，有人可能会说，它的编码方式与“常规 JavaScript”不同。由于一些限制（我这里就不一一提及），我们无法直接将该库导入到我们的代码库中，所以我不得不自己重新引入一些函数和数据类型，并进行了一些细微的调整。我分享了更多关于这些变化的演示文稿，并获得了积极的反馈。

缺乏反对导致我继续深入兔子洞。

新系统完成并测试后，我们必须替换掉散落在代码库各处的旧系统。旧系统在很多地方都有使用，因此从旧系统迁移到新系统的过程非常繁琐。

我这辈子从来没有这么劳累过。我喜欢把旧代码重构成我认为更好的版本，所以没怎么计算时间。在两个月的时间里，我每天大概要花10个小时来做这件事，包括周末。

工作完成后，我休了两周的假（这其实早就计划好了）。在我离开期间，团队不幸遭遇了一起相当严重的事故。他们费了好大劲才找到根本原因并找到解决方案。问题出在新系统内部某个地方，与代码库的其他部分完全不同。团队对它不太熟悉，因为我几乎是唯一一个开发它的人。

在我分享的演讲中，人们理解了这些新工具和实践，并认同这些变化。但是，一旦他们独自置身于这些新奇事物之中，他们理所当然地会感到迷失。

演示固然重要，但如果不练习刚学过的知识，最终还是会忘记。而且，单独演示每个概念和综合运用它们并不相同。这会让本来就很难学习的学科更加复杂。

长话短说，我向我的团队介绍了很多新概念，虽然他们在我演示时表示同意，但我给项目带来的改变极大地损害了他们在我离开后解决关键问题的能力。

当我回来了解到这个事件后，我提出与他们分享更多的演示文稿，以便他们能够更加熟悉新的代码。

其实，我一开始就不应该钻这个空子。这根本不是一个实用的解决方案。字体改进确实很棒，但整个全新的功能系统却是个错误。

你不应该仅仅因为自己觉得这些变化很舒服就给团队带来重要的变化。你必须牢记巴士因素。我以为我会在那个团队待足够长的时间，直到每个人最终都熟悉新的代码，然后我就可以一点一点地教他们。

但这些事情发生几个月后，我加入了另一个团队。回想起来，我对自己在离开团队几个月前放弃这个难以维护的模块感到很内疚，而且差点因此把自己累垮了。

无论你是个人贡献者（又称 IC）还是经理，如果资深团队成员提出了类似这样的重要变革，我强烈建议你认真挑战他们的提议。我相信，在我的案例中，可以找到更好的方案。

如果你和我当时的情况一样，我建议你在做出决定之前三思。这真的是一个务实的解决方案吗？你确定范围定义明确，并且明确了“兔子洞”吗？你这样做是为了团队的利益，还是因为你喜欢？当你不在身边帮助他们时，团队会感到安心吗？

不要让你的情绪在团队面前占据主导地位

我曾经有过这样的经历：在会议期间，我强烈反对经理或同事与团队分享的内容。我让房间里的每个人都知道这让我很困扰，从而公开引发了一场“冲突”。

我想让我的同学们知道，反对别人的决定是可以的。然而，这种行为并不健康：

当冲突变得显而易见时，人们可能会感到不舒服，就像在这种情况下一样。让他们处于这种境地是不公平的。
这可能会造成团队内部的分裂，一些人同意 A 的观点，而另一些人同意 B 的观点。团队必须保持团结才能高效。
总体来说，这体现出人们缺乏自我控制和纪律，以及无法退一步思考当前形势。

我并不是说控制情绪很容易。毕竟，我们是人，不是机器。但尊重同事，避免干扰会议进程也很重要。

我认为，正确的做法是等到会议结束后，然后立即：

去进行一对一会议，与其他人交谈。
或者，与你的经理讨论该情况，并找到解决方法。

在让你感到情绪波动的那场会议结束后，立即开启这种一对一沟通至关重要。时间越长，情况就越糟糕。

根据我的经验，与他人交谈总能帮助改善情况。沟通是关键。没有社交互动，我们在公司（或个人生活中）就无法走得很远。

涉足招聘市场

我以实习生身份加入第一家公司时，和我未来的经理进行了30分钟的面试。就这样。我快速地进行了一次“文化适应”面试，然后就被录用了。

之后，我有七年半的时间没有踏足招聘市场。当我决定离开时，我那短暂的招聘经验显然无法代表我即将面对的局面。当你拥有大约8年的工作经验，申请高级职位时，招聘流程绝对不是仅仅由“30分钟的行为面试”组成。

读完《史上最火爆的科技就业市场》之后，我觉得自己准备好尝试一下了。我更新了我的领英个人资料，并将自己设置为“愿意工作”。

我感到不知所措。处理纷至沓来的工作机会让我精疲力竭。从2021年9月到2021年10月底，我每个工作日大概都会收到5到10个工作机会。我不得不请PTO（个人休假）来处理这个问题，而且我周末的大部分时间都用来处理这件事了。

起初，我能回复每一条招聘人员的信息。但是，当我遇到以下情况时：

我必须整天工作，因为当时我还在目前的公司工作。
我当时正准备搬到另一个城市，这对我来说压力很大。
我参与了几家公司的招聘流程。
我不断收到新的工作建议。

回复招聘人员发来的所有新消息变得越来越困难。

我最终写了自己的信息模板，写下了我对下一份工作的期望。我尽可能多地分享了细节：公司规模、工程师文化、远程工作、薪酬、技术挑战等等。但尽管如此，我还是没能及时回复所有信息。

对于当时联系过我，而我却没有机会回复的招聘人员，我深感抱歉。我当时真的不知所措。

但处理 LinkedIn 消息并不是最难的部分。最累的部分实际上是面试。我之前从未有机会学习 DSA（数据结构和算法），因为我从未觉得有必要换公司。

我主要在leetcode上进行训练，并且还购买了几本书来帮助我：

破解编码面试，作者：Gayle Laakmann McDowell。
系统设计访谈第 1 卷，作者：Alex Xu。

此外，我还必须详细地回忆并展示我参与过的一些最有影响力的项目。这时，我们之前提到的工作日志就变得非常有用了。

当我最终接受了一份 offer 后，我向经理递交了辞呈。如果我没记错的话，这份 offer 的基本工资增加了 25%，还附带一些额外福利，而且就我目前的工作（远程办公）而言，员工福利总体上也更好。

我鼓励你时不时尝试面试的原因如下：

在此过程中，您将获得一些经验，因此，当最终加入一家新公司时，您将不会感到不知所措。
你可以检查一下自己在市场上的价值，并可以向目前的公司申请一些薪酬调整。如果你能拿到工作邀请，这很可能会帮助你更好地获得你认为在当前职位上应得的待遇。

在我的第一家公司，除了最后一年，我的工资涨幅都不错（每年都在7%到10%之间）。虽然我对去年的加薪并不满意，但我觉得明年的加薪幅度应该会更大。

由于我在那家公司工作的大部分时间里都获得了不错的加薪，所以我从来不想去看看自己在招聘市场上的价值。真希望我早点这么做。这并不一定意味着我会早点离开那家公司，但至少我可以积累一些经验，而且我或许可以要求调整薪水而不是加薪。

别误会我的意思：加薪 10% 固然很好。但如果你的薪水比市场预期低 15% 到 20%，那么最终这 10% 的加薪也不够。你怎么才能知道自己是否得到了应得的薪酬呢？答案是：亲身体验市场行情。此外，还要与之前经历过市场行情的同事保持联系。

参加面试并不会迫使你离开公司。你可以在现在的公司参加几十次面试，只要你不为了面试而牺牲工作。这就是为什么我不得不休带薪休假，而且不得不在清晨和午休时间进行面试。

结束思考

首先，感谢您阅读到这里！希望本文对您有所帮助。我想您已经注意到，所有这些建议其实都不是技术性的。它们大多是关于软技能的。也许我会再写一篇文章，提供一些更侧重于技术技能或硬技能的建议。如果您对这些内容感兴趣，请告诉我。

最后我想和大家分享一件事：和你以前的同事保持联系，尤其是那些曾经激励过你的人。他们是你敬佩的人，因为他们按照你的标准做得很好。他们可能是优秀的经理，也可能是你真正欣赏的、有影响力的技术领导者。这一点很重要，因为他们会帮助你进步，成为更优秀的开发者。他们甚至可能会说服你加入他们的公司/团队，只要频率合理，这样做是有益的。每个人都应该建立一个能够帮助自己成为更好的人脉网络。

如果您有机会尝试这些建议，并且最终有效，请分享您的经验。我非常期待听到大家对这些建议的反馈，看看它们是否也适用于我以外的其他情况。

一如既往，欢迎在评论区分享你的观点！下次再见 :)

照片由Simon English在Unsplash上拍摄。

文章来源：https://dev.to/ruizb/advices-from-a-software-engineer-with-8-years-of-experience-2n0l

一位拥有 8 年经验的软件工程师的建议

一位拥有 8 年经验的软件工程师的建议

目录

我的职业发展历程

我希望早点开始做的事情

写工作日志

离开舒适区

对其他团队和项目保持好奇心

加入值班团队

更换团队

撰写博客文章

我希望自己能以不同的方式做事

向团队介绍新事物时要小心

不要让你的情绪在团队面前占据主导地位

涉足招聘市场

结束思考