一位拥有 8 年工作经验的软件工程师的建议
你好，欢迎来到这里！
我叫 Benoit。在过去的八年半里，我一直是一名软件工程师。我在上一家（也是第一家）公司待了七年半，然后在 2022 年初加入了一家新公司。
这篇文章来自于我最近的一次自我反思，反思我希望在职业生涯中更早开始做的事情，以及我希望以不同方式做的事情。
我在这里分享的内容可能对任何希望得到提高并向高级及以上职称迈进的初级到中级开发人员都有帮助。
Table of Contents
· My Career Evolution
· Things I Wish I Had Started Doing Earlier:
∘Write a Work Log
∘Leave the Comfort Zone
∘Be Curious About Other Teams and Projects
∘Join the On-call Team
∘Change Teams
∘Write Blog Posts
· Things I Wish I Had Done Differently:
∘Be Careful When Introducing New Things to the Team
∘Do Not Let Your Emotions Take Over in Front of the Team
∘Dip a Foot Into the Hiring Market
·End Thoughts
我的职业发展历程
在进入正题之前，先介绍一下我的职业发展历程：
- 我曾在一家初创公司（很快就发展壮大了）实习了三个月。
- 之后，我做了一整年的勤工俭学，三个月在学校，九个月在公司。
- 然后，我被聘为全职软件工程师，这一职位一干就是三年半。
- 在引入技术职业阶梯后，我很快晋升为高级软件工程师。这个头衔我一直保留了三年，直到我离开公司，当时技术团队大约有 200 人。
- 我以软件工程师 2 的身份加入了一家拥有数千名技术员工的公司。尽管在第二家公司的头衔降级了（参见《大科技公司的招聘很保守--但为什么？》），但我一直在努力保持与以前相同的职责（甚至更多）。
我过去 8 年半的职业发展示意图。
起初，我是前端团队的一员。技术组织由后端和前端开发人员组成。当时，我们的工程师不超过 30 人。一年后，我们的新首席技术官到任，他引入了基于功能团队的组织架构：Spotify 模式。虽然一开始有一些摩擦（人们不喜欢改变），但这次重组肯定是为了更好地发展。
我在同一个功能团队工作了五年多。团队成立之初我就在那里，所以这些年来，我成了这个项目的技术顾问。最后，我加入了另一个团队，在那里一直工作到一年后离开，开始了全新的冒险。
好了，背景介绍到此为止。我希望你会喜欢阅读下文，并希望以下建议对你的职业发展具有可操作性！
我希望早点开始做的事情
撰写工作日志
工作日志是一份包含你所完成任务清单的文件。任务的粒度和类型并不重要，重要的是你记录了自己做了什么。
你可以按照自己的频率填写这份文件。我建议每周填写一次。一周内完成的任务在周五仍然新鲜，所以你写起来不会很费劲。
为什么工作日志很重要？有以下两个原因：
- 提醒自己在过去 6 到 12 个月里做过的所有事情。这在绩效考核时非常有价值，你可以向经理展示你所取得的成就，以及为什么你值得加薪或晋升。
- 跟踪您在职业生涯中的项目、重要职责和关键数字（例如，将关键服务的延迟时间减少 X%）。无论何时，只要你想进入招聘市场，这都是完成简历的好帮手。
我大概是在离开第一家公司的两年前开始写工作日志的。因此，在过去的八年半时间里，我的工作日志只包含了三年的数据（偶尔会有一些空白）。2021 年末，当我需要撰写简历时，我不得不依靠记忆来回忆我在职业生涯前五年所做的工作。至少可以说，我花了一些时间才记住所有有价值的事情，而且我肯定忘了其中一些。
如果你愿意，可以使用工作日志模板（这里有一个例子）。就我个人而言，前两年我一直使用 Microsoft Notes，后来我改用带要点的 Google Doc（一年中每个月都有一个清单）。
离开舒适区
这是学习并成为更好的开发人员的最佳途径。舒适区是指你在工作中感到舒适的范围和环境。它是你已经熟悉并每天一起工作的队友，是你已经工作多年的项目，是你一直承担的责任，等等。
但是，为什么有人会建议你离开这个美好的环境呢？因为这种环境不适合进化。
当然，如果你留在这个泡沫中，你就是一个高效率的人。你已经知道该和谁讨论某个特定主题，也知道代码库中的哪个文件需要修改。但有什么比一个高效的人更好呢？几个高效的人！
一旦你在某个特定主题上达到了舒适区，你就应该寻找：
- 指导他人，让他们对这一主题驾轻就熟。
- 在你的 "舒适区 "之外寻找新的工作。
指导是高级职位应尽的职责之一。这是帮助同事快速提高效率的好方法。你将成为力量倍增器。
至于要做的新事情，可以是任何事情。以下是一份不完全的清单，供大家参考：
- 为团队/组织的某个项目献计献策，你以前从来没有机会接触过这个项目，例如，因为这个项目总是分配给同一个人（他在自己的舒适区）。
- 就自己熟悉的主题撰写文档。这样做的目的是分享你的知识，并间接指导他人，让他们比你更快地掌握这些知识。此外，写作也是一项值得学习和提高的技能，无论是文档、电子邮件、即时信息、RFC（征求意见）还是博客文章等。
- 志愿参与跨团队项目。你甚至可以在这些项目中担任领导职务，一举两得。
- 负责改进工具、监控或团队/组织流程。
- 参加公司组织的聚会。
- 加入公司的社区/公会，参与组织级的跨团队项目。
- 帮助招聘团队进行技术面试，和/或检查应聘者的带回家练习。
目的是学习新知识。绩效考核可以帮助你明确在走出舒适区时应该做什么，以及如何去做。但你不必等到这个时候才行动。只要你的经理知道，你随时都可以这么做。例如，你可以在 1-1 会议上谈论此事。你的经理的核心目标之一就是帮助你在职业生涯中取得进步，因此我强烈建议你在离开舒适区之前先与他们谈谈。
有些话题你可能并不关心。就拿我来说，在很长一段时间里，我都不想学习任何与机器学习和数据分析相关的知识。但是，我的好奇心和求知欲最终将我引向了这些主题。尽管我没有机会参与基于这些领域的公司项目，但我很高兴自己了解了这些领域。与同龄人进行有意义的对话是一件很棒的事情，它甚至可以帮助我找到没有这些知识就无法获得的想法。
如果你想在职业生涯中取得进步，我强烈建议你离开自己的舒适区，一有机会就学习新东西。我敢肯定，这个建议也适用于个人生活！
对其他团队和项目充满好奇
这一条与上一条很接近，不过你不必认可额外的责任。
很长时间以来，我都不关心自己团队范围之外的团队和项目。我们的产品与其他团队的服务有一些依赖关系，但只要他们和我们之间的应用程序接口定义明确，我们就不必了解他们的服务。
只有当我们必须为这些项目做出贡献时，我们才不得不打开盒子，看看事情是如何运作的。由于我们是按功能团队组织的，如果我们需要对公司的其他项目进行一些修改，我们就必须自己进行修改。每个功能团队都有自己的路线图，因此我们不能要求其他团队代劳。虽然一开始我们做得很慢，但在其他团队的帮助下，我们逐渐提高了为他们的项目做贡献的效率。
但是，对于与我们没有直接互动的其他服务，我不知道它们是如何工作的，也不知道它们在系统中的确切角色是什么。几年后，当我加入值班团队时，我才真正开始了解公司的所有服务。当我终于了解了全部情况后，感觉非常好。
- 我更清楚地了解到，当事情出错时，罪魁祸首可能是什么。
- 我知道了为什么我们需要那种特定的服务，或者为什么我们要选择那种数据存储。
- 最后，在为公司创造价值多年之后，我终于把一切都拼凑在了一起，这让我有一种 "哦，现在我明白了 "的美妙感觉。
如果可以的话，看看你公司的其他项目和团队。阅读他们的内部维基页面，参加他们的演示，阅读他们的公开文档。这是你可以时不时做的事情，不一定要持续努力。额外的收获：如果你能画一张图并写一些关于 "全貌 "的文档，那就去做吧。组织中的很多人可能会因此感谢你！
请注意，与前面关于舒适区的建议相比，在这里你不需要做任何事情。你所需要做的就是保持好奇心，阅读其他团队的文档并提出问题。一路上，你可能会遇到其他团队的人，也可能会发现自己真正想参与的项目。
加入待命团队
这一条可能会引起争议，而且在你的公司可能根本不可能做到。当然，只有当你的公司有一个健康的随叫随到环境时，你才应该考虑这个建议（参见《软件工程师的随叫随到报酬》）。
随叫随到团队由愿意在工作时间内外（即夜间、周末和银行假日）出错时进行干预的人员组成。您的公司可能有专门的 SRE（网站可靠性工程师）团队，和/或您的团队可能不负责DevOps 工作。
但是，如果你有可能加入待命团队，不管是为你工作的产品，还是为整个公司（取决于公司规模），我都建议你加入。
以下是加入这个团队的一些好处：
- 你会了解到很多使公司蓬勃发展的产品和服务的 "幕后 "工作。
- 你对同事更有同理心，因为每当发生不好的事情时，尤其是在晚上，你会体验到责任的重大。
- 你对公司的投入感更强，因为你会投入更多的时间来确保产品和服务按照预期为客户服务。
同样，在承担这些责任之前，需要一个健康的待命环境。
在我的第一家公司，我在离职前大约两个月加入了值班团队（负责所有服务）。我希望自己能早点加入，因为在这几个月里我学到了很多东西，而且这份额外的责任也得到了很好的补偿。
在我现在的第二家公司，我在第一天上班的两三个月后加入了值班团队（负责单一产品的服务）。目前，我只在工作时间介入，但最终我将能够在夜间和周末回复页面。
更换团队
我认为有三个原因可以解释您为什么要换团队：
- 你在目前的职位上太舒服了，你想离开你的舒适区。
- 您不太喜欢团队的项目/范围，希望从事自己更喜欢的项目。
- 与同事和/或经理的关系恶化，你想呼吸新鲜空气，同时仍然是公司的一员。
如果你发现自己处于上述情况之一，那么我鼓励你考虑组建一个新的团队，而不是辞职并寻找新的公司。
换一家新公司会让人精疲力竭，而且你可能会失去一些你真正欣赏的东西，比如同事、工程文化或员工福利。
我认为团队跳槽非常好，原因如下：
- 新团队的组织结构可能不同（仪式、合作方式），因此你可以在这一领域获得更多经验。
- 你可以把从上一个团队学到的积极变化（改进代码审查流程、工具、库和仪式）带到新团队，从而成为公司的良好实践倡导者。
- 当你的新队友需要参与前团队的项目时，你可以帮助他们（即知识从一个团队有效地传播到另一个团队）。
- 你可以学习新的工具、语言、库、架构和解决问题的方法。换句话说，你可以成为一名更好的开发人员。
- 如果你是因为前面提到的第 2 或第 3 个原因而改变的，那么你可能会在更好的条件下工作。
在离开第一家公司的前一年，我决定换一个团队。有几个团队邀请我加入他们，如果我能把自己分成多个部分，我会很乐意加入他们。
加入新团队后，我感觉自己的高级职称不再合法。我必须学习新的代码库、工具和实践。当然，我保留了我的软技能和对业务/产品的了解，但我的技术技能受到了打击。当然，学习新知识是件好事，但我不再是团队的技术指标了。不过，每当团队需要为我之前团队的项目出谋划策时，我都能以更有效的方式帮助他们。随着时间的推移，"配不上我的头衔 "的感觉逐渐消失了，而我也随着掌握更多的技能而变得更加出色。
尽管如此，我认为更换团队的频率不应过高。我在第一个团队待了五年多，然后换到新团队一年，最后因为与新团队无关的原因离开了公司。
如果您觉得您的情况符合上述三种原因之一，我会建议您考虑更换，但前提是您必须在当前团队至少待满一年。我认为一年的时间是合理的，可以让你感觉到自己是否属于现在的团队。如果你等不了一整年，那就意味着情况非常危急，我建议让你的经理和/或他们的经理参与进来，以解燃眉之急。
撰写博客文章
这一条应该只是 "写"，但感觉太短了。写作是开发人员应该掌握的最重要的技能之一。我们的很多日常工作都涉及写作：代码、信息、电子邮件、文档、RFC、会议记录、事件后记等。
写作是与人交流的最佳异步方式之一。他们可以根据自己的需要随时阅读你的信息，而且不会在执行任务时被打断，可以集中精力完成任务。当然，在某些情况下，同步沟通是更好的沟通方式，如视频通话、面谈等，以解决一些紧急问题或消除歧义和误解。但根据我的经验，开发人员日常接触更多的是写作，而不是交谈。
撰写博文之所以有趣，原因如下：
- 熟能生巧。提高技能的唯一途径就是练习。如果你不确定自己是否做对了，你可以向在你看来做得很好的人寻求帮助，让他们在这方面指导你。你也可以阅读相关的文档和博文。尽管如此，最重要的是开始练习，即使你的第一篇文章有一些缺陷。
- 这将迫使你了解你正在谈论的主题。这是一种真正学习知识的好方法--比平时更深入地研究某一特定主题。
- 培养个人品牌。对你的博文感兴趣的人越多，你的追随者就越多，你的影响力也就越大。
您可以在个人博客和/或公司博客上撰写文章。为公司撰写文章在一开始是很好的，因为它已经有了读者和追随者基础。不过，你在谈论主题方面的自由度较低，因为这是公司的选择。
不要指望第一篇博文发表后就会大受欢迎。要成为有影响力的人需要很长时间。你甚至可能永远达不到那一刻，这也没关系。你应该为自己写作，提高写作技巧，与社区分享你的发现。你不应该在乎得到多少赞或粉丝。是的，获得这样的认可会极大地鼓舞士气，但你的目标不应该是增加这些数字。你的目标应该始终是提高写作水平和分享知识。
我在第一家公司的工程博客上发表文章，开启了我的写作之旅：在网页浏览器中调度函数的最准确方法。这篇文章甚至在《JavaScript 周刊》上被提及，感觉棒极了。
然后，在 2021 年 3 月，我开始在Dev.to 上撰写博文，并偶尔继续这样做。我还在 HackerNoon 上发表了一篇文章，但我不太喜欢他们对标题的编辑，我觉得 Dev.to 将是我的主要博客媒体，至少现在是这样。
我希望有不同做法的地方
向团队介绍新事物时要谨慎
资历越深就越要注意这一点，不过即使是初学者也应该觉得自己有能力向团队引入新事物，无论是库、语言、范式还是合作方式等等。作为后辈，你更容易受到团队中前辈的挑战。不过，你的资历越深，就越容易说服别人，尤其是年轻人。
在我的第一家公司，在调到另一个团队的几个月前，我处于一个可以对代码库提出......雄心勃勃的改动的位置。当时，我已经学习了几年函数式编程范式，对它的优势深信不疑。
在几个月的时间里，我向包括我在内的两个团队介绍了函数式概念。需要说明的是，这些介绍是在我对代码库进行重大修改之前进行的。
我认为这些培训课程足以说服人们采用这种新模式。那一刻，事实的确如此：大家都在点头。他们理解了新的概念、利弊以及我们可以用来改进项目的方法。
在这些介绍之后，我们看到了一个机会：
- 当时正值初夏，商业活动将在几个月内变得相当缓慢。
- 在今年上半年，我们遇到了一些错误，不得不在一个最老的系统中使用肮脏的变通方法。
- 通过使用功能概念和 TypeScript（又名 TS）类型，我们可以大幅改善该系统的可测试性和开发人员体验。这个旧系统最初是作为 TS 的早期版本开发的，没有提供强大的类型功能。
换句话说，这是进行重构的最佳时机！我向团队展示了一个概念验证，通过使用函数式和类型级编程与 TS，大大改进了该系统。我们都对它的优点深信不疑，并决定进一步实施可投入生产的系统。我负责创建任务、规划可以并行完成的工作等。我在 Slack 频道上定期发布更新，让利益相关者可以跟踪进度。
我在我们自己的代码库中开发了该系统的第二版库，使其成为一个独立模块，可以测试我们能想到的所有可能的边缘情况，并使用单元测试，因为副作用终于得到了控制。尽管引入了很多新的概念、函数和代码改动，但大家都很满意。我在代码审查时获得了批准。
我深受fp-ts 库的启发，可以说它的编码方式不同于 "常规 JavaScript"。由于一些限制因素，我们不能简单地将该库导入我们的代码库，所以我不得不自己重新引入其中的一些函数和数据类型，并稍作调整。我在更多的演示中介绍了这些改动，并得到了积极的反馈。
没有人反对，我就继续深入研究。
新系统完成并经过测试后，我们必须替换掉散落在代码库各处的旧系统。它被用在很多地方，因此从旧系统迁移到新系统的过程非常繁琐。
我一生中从未如此劳累过度。我喜欢把旧代码重构成我认为更好的版本，所以我没有计算工时。在两个月的时间里，我每天大概要花 10 个小时工作，包括周末。
工作完成后，我请了两周假（计划已久）。在我离开期间，团队不幸发生了一起相当重要的事故。他们费了九牛二虎之力才找出根本原因，并找到了解决方法。问题出现在新系统中，与代码库的其他部分看起来并不一样。团队对它并不熟悉，因为几乎只有我一个人开发了它。
在我的介绍过程中，大家理解了这些新工具和新做法，并同意这些改变。但是，一旦他们独自一人置身于这些新奇的事物中，就会理所当然地感到迷茫。
演讲是一件事，但如果你不去实践你刚刚学到的东西，你最终会忘记它。另外，分别介绍每个概念并不等于一并使用。这让本来就很难学的内容变得更加复杂。
长话短说，我向我的团队介绍了很多新概念，虽然他们在我的介绍过程中都接受了，但我给项目带来的变化极大地损害了他们在我离开期间解决一个关键问题的能力。
当我回来得知此事后，我主动提出与他们分享更多的演示，以便他们能更熟悉新代码。
实际上，我一开始就不应该进入这个兔子洞。这不是一个务实的解决方案。类型改进固然很好，但整个新功能系统却是个错误。
你不应该仅仅因为自己对这些变化感到满意，就给团队带来重要的变化。你必须牢记总线因素。我以为我会在那个团队呆足够长的时间，每个人最终都会熟悉新代码，我可以一点一点地教他们。
但是，在这些事件发生几个月后，我加入了另一个团队。现在回想起来，我很后悔在离开团队前几个月放弃了这个难以维护的模块，差点因此把自己累垮。
无论你是个人贡献者（又称 IC）还是经理，如果资深队友引入了像这些这样的重要变更，我强烈建议你真正挑战他们的主张。我相信，在我的情况下，可以找到更好的折衷方案。
如果你和我的情况一样，我鼓励你在做出承诺之前三思而后行。这真的是一个务实的解决方案吗？你确定范围界定得很清楚，兔子洞也确定得很清楚吗？你这样做是为了团队好，还是因为你喜欢？当你不在他们身边帮助他们的时候，团队会接受吗？
不要在团队面前控制情绪
我曾在会议上强烈反对经理或同事与团队分享的内容。我让会议室里的每个人都知道这让我很困扰，从而公开挑起了一场 "冲突"。
我想让我的同事们知道，不同意别人的决定是没有问题的。然而，这种行为并不健康：
- 当冲突变得明显/显而易见时，人们可能会感到不舒服，比如在这种情况下。让他们陷入这种境地是不公平的。
- 这可能会在团队内部造成分裂，一些人同意 A 的意见，另一些人则同意 B 的意见。
- 一般说来，这表明有些人缺乏自制力和纪律性，也有些人不能退一步考虑问题。
我并不是说控制情绪很容易。毕竟，我们是人，不是机器。但同样重要的是，我们要尊重同伴，避免干扰会议进程。
在我看来，正确的做法是等待会议结束，然后立即：
- 在 1-1 会议上与对方交谈。
- 与你的经理谈谈情况，找到解决问题的办法。
重要的是，要在会议结束后立即启动这种 1-1 会议，因为会议让你感到情绪激动。时间过得越久，情况就会越糟糕。
根据我的经验，与对方交谈总是有助于改善情况。沟通是关键。没有社交互动，我们就无法在公司（或个人生活）中走得更远。
涉足招聘市场
当我以实习生身份加入第一家公司时，我与未来的经理进行了 30 分钟的面试。就这样。我做了一个快速的 "文化适应 "面试，然后就被录取了。
从那以后，我有七年半的时间没有踏足招聘市场。当我决定离开时，我在招聘市场上单一而短暂的经历显然不能代表我将要面对的情况。当你以大约八年的工作经验申请高级职位时，招聘过程绝对不仅仅是 "30 分钟的行为面试"。
读完《史上最激烈的技术人才招聘市场》一书后，我觉得自己已经做好了尝试的准备。我更新了自己的 LinkedIn 个人资料，然后将自己设置为 "开放工作"。
我感到不知所措。面对纷至沓来的求职信息，我疲惫不堪。从 2021 年 9 月到 2021 年 10 月底，我每个工作日都要收到 5 到 10 份工作邀请。我不得不利用 PTO（个人休假）来应对这种情况，我还花了大量的周末时间来处理这些问题。
起初，我还能回复每一位招聘人员的信息。但是，当我遇到这种情况时：
- 我必须整天工作，因为当时我还受雇于现在的公司。
- 我正准备搬到另一个城市，这对我来说压力很大。
- 我正在参与几家公司的招聘过程。
- 我不断收到新的工作邀请。
我越来越难以回复招聘人员发来的所有新信息。
最后，我自己编写了一个信息模板，其中包含我对下一份工作的愿望。我尽可能多地分享了一些细节：公司规模、工程文化、远程工作、薪酬、技术挑战等等。但尽管如此，我还是无法跟上所有的信息。
对于所有当时联系过我，但我一直没有机会回复的招聘人员，我深表歉意。当时的情况让我不知所措。
但处理 LinkedIn 信息并不是最困难的部分。最累的是实际面试。我以前从未有机会接受过 DSA（数据结构与算法）培训，因为我从未觉得有必要换一家公司。
我主要在leetcode 上进行培训，还买了几本书来帮助自己：
此外，我还必须记住并详细介绍我参与的一些最有影响力的项目。这就是我们之前提到的工作日志可以成为非常有趣的资产的地方。
我最终接受了公司的聘用，并向经理递交了辞呈。如果我没记错的话，这份新工作给我增加了 25% 的基本工资。其中还包括一些额外的补偿，以及针对我的情况（远程工作）提供的更好的员工福利。
我鼓励你时不时尝试面试的原因就在于此：
- 你可以在面试过程中积累一些经验，这样当你最终加入一家新公司时，你就不会感到那么不知所措了。
- 您可以在市场上检验自己的价值，并有可能要求调整当前公司的薪酬。如果你能获得工作机会，很可能会帮助你获得你认为在目前职位上应得的报酬。
在我的第一家公司，除了最后一年，我的加薪幅度都不错（每年在 7% 到 10% 之间）。尽管我对最后一年的加薪并不满意，但我认为无论如何我都会在第二年获得更好的加薪。但那一刻从未到来，因为我在加薪之前就辞职了。
因为我在那家公司的大部分职业生涯都得到了很好的加薪，所以我从未想过要在招聘市场上看看自己值多少钱。我真希望能早点这么做。这并不一定意味着我会更早离开公司，但至少我会积累一些经验，而且我有可能要求调薪而不是加薪。
别误会我的意思：加薪 10%是件好事。但是，如果你的薪水比市场对你的评价低 15%-20%，那么到头来，10% 的加薪并不够好。如何才能知道自己是否得到了应得的报酬呢？亲身经历市场。此外，还要与亲身经历过市场的前同事保持联系。
面试不会迫使你离开公司。只要你不为面试而牺牲工作，你可以在目前的公司做几十个面试。这就是为什么我不得不利用 PTO，不得不在清晨和午休时间进行面试。
结束语
首先，感谢您阅读本文！希望这篇文章对你有用。我想你已经注意到了，所有这些建议都不是真正的技术性建议。其中大部分都是关于软技能的。也许我会再写一篇文章，提供更多关于技术技能或硬技能的建议。如果你对此类内容感兴趣，请告诉我。
最后，我还想和大家分享一件事：和你以前的同事保持联系，尤其是那些曾经激励过你的人。他们是你钦佩的人，因为他们按照你的标准做了出色的工作。他们可能是你非常欣赏的优秀经理或有影响力的技术领导。这一点很重要，因为他们会帮助你不断进步，成为一名更好的开发人员。他们甚至可能说服你加入他们的公司/团队，只要频率合理，这都是健康的。每个人都应该建立一个网络，帮助自己成为更好的人。
如果您有机会尝试这些建议，而且效果不错，请分享您的经验。我很想得到关于这些建议的反馈，看看它是否适用于我自己以外的其他情况。
请随时在评论中分享您的观点！下次见 :).
0 Comments