导读：为那些想要职业发展的人提供的实用技巧。

大家好，欢迎光临本文！

过去八年半以来，我一直担任软件工程师。我在之前（也是第一家）公司待了七年半，然后在 2022 年初加入了一家新公司。

这篇文章来自我希望在职业生涯早期就开始做的事情，以及我希望自己以不同的方式做事情的自我反思。

我在这里分享的内容可能对任何希望提高并取得高级及更高级别头衔的初级到中级开发人员都将有益。

0 大纲

我的职业发展
我希望早点开始做的事情:
记工作日志
走出舒适区
好奇其他团队和项目
加入值班团队
换团队
写博文
我希望以不同的方式做的事情:
在向团队引入新事物时要小心
不要在团队面前让情绪占据主导
在招聘市场里探个底
结束思考

1 我的职业发展

我在一家创业公司(很快成为规模公司)实习了三个月。之后，我做了一年工作学习，每三个月在学校学习，九个月在工作。

然后，我被聘为全职软件工程师，后面保持这一头衔三年半。

在引入技术职业阶梯后不久，我被晋升为高级软件工程师。我保持这个头衔三年，直到离开这家公司，这时技术团队约有200人。

我以软件工程师的身份加入了一家拥有数千名技术员工的公司。尽管在第二家公司职称有所降级，但我一直在努力保持与以前相同甚至更多的职责。

我过去8年半的职业发展历程图示：

刚开始，我是前端团队的一员。公司的技术团队分为后端和前端开发人员。那时，我们不超过30名工程师。

一年后，我们的新CTO到来，他引入了一个基于特性团队的组织模型：Spotify模型。尽管一开始产生了一些矛盾，人们并不喜欢改变，但这种重组绝对是朝着更好的方向发展的。

我在同一个特性团队呆了五年多。我参与了它的创立和发展，所以这些年来，我成为了该项目的技术顾问。最终，我加入了另一个团队，在那里我一直工作到一年后离开公司开始全新的探险。

2 我希望早点开始做的事情

2.1 写工作日志

工作日志是包含已完成任务列表的文档。任务的粒度和类型并不怎么太重要，只要记录所做的事情即可。

你可以以自己想要的频率编写此文档。我建议每周填写一次。周五对当周的任务还记忆犹新,所以你不会在写下来时感到困难。

为什么工作日志很重要？基于如下两个原因:

• 提醒自己在过去6到12个月中做过的所有事情。这对绩效评审非常有价值,所以你可以向经理展示自己完成的工作和应得的加薪或晋升。

• 跟踪你职业生涯中的项目、显着职责和关键数据(例如,降低某关键服务的延迟X%)。

这对完善简历非常有用，无论何时你想进入招聘市场的“水域”。

我在离开第一家公司约两年前开始记工作日志。所以,在过去的八年半中，我的工作日志只包含三年的数据（存在有一些间隙）。

当我在2021年底不得不写简历时，我不得不靠记忆来记住职业生涯前五年做的事情。现在说实际上对自己并不负责，轻描淡写，我知道做了很多事。我花了不少时间记起所有有价值的东西，但肯定的是忘记了其中一些，甚至是重大的。

如果你愿意，可以使用工作日志模板。就我个人而言,头两年一直使用微软Notes，然后我转到Google文档的Project chat（每年一个列表）。

2.2 走出舒适区！

这是学习与成为更好开发者的最佳方式。

舒适区是你感到舒适完成工作的范围和环境。它是你每天共事的队友、你多年来一直在工作的项目、你一直在承担的职责等等。

但是为什么有人会建议你离开这种美好的情况呢？因为这种环境并不适合进步。

当然，如果你想留在这个泡泡中，你就成为一个高效的人。你已经知道在某个具体主题上该与谁交谈，并知道代码库中需要更改的文件。

但是，一个高效的人怎么可能比数个高效的人更好呢!

一旦你在某个主题上进入舒适区,你应该寻找:

• 指导别人，这样他们也能对这个主题感到舒适

• 寻找舒适区之外的新事物，并达成

辅导是高级职位人士的责任之一。这是帮助我们的同事快速提高效率的绝佳方式。

你成为团队的一个力量倍增器。

至于要做的新事物，可以是任何你感兴趣的事情。这里有一些灵感的非详尽清单:

• 为你以前从未有机会接触的团队/组织项目做出贡献。例如，因为它一直被分配给同一个人(谁处于他们的舒适区)。

• 写关于你熟悉主题的文档。目标是分享你的知识，并间接指导别人，以便他们比你更快地获取这些知识。此外，写作是一项很棒的技能，无论是文档、电子邮件、即时消息、RFC(评论请求)、博文等都需要这项技能。

• 志愿参与跨团队项目。你甚至可以在这些项目期间担任领导职务，以便一箭双雕。

• 负责改进工具、监控或团队/组织流程。

• 参加公司组织的聚会。

• 加入公司的社区/小组，以便针对组织级跨团队项目开展工作。

• 通过进行技术面试和/或检查候选人的带回家作业来帮助招聘团队。

我们的目标是学习一些新知识。

绩效评审可以帮助你定义在走出舒适区，要做什么以及如何做。

但是你不必等到那一刻才采取行动。只要你的经理知晓，你可以随时这样做。例如,你可以在1对1会议上讨论它。你经理的核心目标之一是帮助你职业发展，所以我强烈建议在离开舒适区之前与他们好好讨论。

你可能对某些主题不太关心。就我个人而言,很长一段时间里，我不想学习任何与机器学习和数据分析有关的东西。但我的好奇心和对知识的渴望最终引导我走上这些主题的道路。尽管我没有机会在公司项目中从事这些领域的工作，但我也很高兴我了解了这些知识。

与同龄人进行有意义的交流，这也很棒，它甚至可以帮助我找到没有这些知识就无法获得的想法。

如果你想在职业生涯中取得进步,我强烈建议你每次有机会时都要离开舒适区并学习新事物。我相当确定这个建议也适用于一个人的个人生活!

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

这一点与上一个很相近，不过你不必承担额外的责任。

很长一段时间以来，我并不关心团队和项目之外的团队和项目。我们的产品与其他团队拥有的服务之间存在一些依赖关系，但只要它们之间的 API 界定明确，我们就不需要知道关于其服务的任何信息。

我们不得不打开盒子并看看事情是如何工作的唯一时间是当我们不得不为这些项目做出贡献时。由于我们按特征团队组织，如果我们需要对公司的其他项目进行一些更改，我们必须自己进行这些更改。每个特性团队都有自己的路线图，所以我们不能要求另一个团队为我们做这项工作。尽管我们刚开始很慢，但在其他团队的帮助下，我们在为他们的项目做出贡献时逐渐变得更有效率。

但是，对于我们没有直接交互的其他服务，我对它们的工作方式以及它们在系统中的确切作用一无所知。多年后，当我加入值班团队时，我才真正开始查看公司的所有服务。当我终于看到整个画面时，感觉很棒。

当事情出错时，我更好地理解了可能的罪魁祸首。

我知道我们为什么需要那个特定的服务或为什么我们做出那个数据存储选择。

最终，将一切拼凑在一起，在多年为公司创造价值之后，产生了一种“噢，现在我明白了”的感觉。

如果可以，请查看公司其他项目和团队。阅读他们的内部维基页面，参加演示，并阅读他们的公共文档。这是你可以不时做的事情;它不必是持续的努力。额外奖励:如果你可以绘制图表并编写有关“全景图”的一些文档，请这样做。组织中的许多人会感谢你的!

请注意，与前面的关于舒适区的建议相比，在这里你不需要生产任何东西。你所需要的只是保持好奇心，阅读其他团队的文档，并提出问题。你可能会在此过程中遇到来自其他团队的人，并且你可能会发现你真正想要工作的项目。

2.4 加入值班团队

这一点可能有争议，在你的公司可能甚至无法实现。当然，只有在你的公司拥有健康的值班环境时，你才应考虑这个建议(参阅软件工程师的值班补偿)。

值班团队由愿意在工作时间内和之外(即夜间、周末和节假日)在出现问题时进行干预的人组成。你的公司可能有专门的 SRE(站点可靠性工程师)团队，和/或你的团队可能不负责 DevOps 工作。

但是，如果你有可能加入值班团队，无论是为你工作的产品，还是为整个公司(取决于其规模)，我建议你这样做。

加入这个团队的一些好处如下:

你将对使公司蓬勃发展的产品和服务的“幕后”有很多了解。

当出现不好的事情时，尤其是在夜间，你会更能体会到责任的重量，对同事们更有同情心。

你会更多地投入精力确保客户按预期使用产品和服务，因此你会更加投入公司。

同样，健康的值班环境是担负这些责任之前的必要条件。

在第一家公司，我在离开前约两个月加入了值班团队(负责所有服务)。我希望我早点加入，因为我在这几个月中学到了很多，这种额外的责任也得到了很好的补偿。

在我的第二家也是目前的公司，我在第一天后两个到三个月内加入了值班团队(仅负责单一产品的服务)。目前，我仅在工作时间内接听页面，但最终我也可以在夜间和周末响应页面。

2.5 更换团队

我可以看到你移动到另一个团队的三个原因:

你在当前职位上过于舒适，并希望走出舒适区。

你实际上不喜欢团队/范围的项目，并希望从事你更享受的项目。

你与同事和/或经理的关系恶化，你想在公司继续呆着的同时呼吸一下新鲜空气。

如果你发现自己处于这些情况下的一种，那么我鼓励你考虑新的团队，而不是辞职并寻找新公司。

换到新公司是非常耗费精力的，你可能会失去你真正欣赏的东西，比如同事、工程文化或员工福利。

我认为团队跳槽对以下原因很棒:

新团队的组织可能不同(仪式、共同工作方式)，所以你在这方面获得了更多经验。

你可以带来从前团队学到的积极变化(改进代码审查流程、工具、库和仪式)，从而成为公司的良好实践倡导者。

当他们需要使用你前团队拥有的项目时，你可以帮助新队友(即从一个团队高效地将知识传播到另一个团队)。

你可以学习新工具、语言、库、架构和解决问题的方法。换句话说，成为更好的开发人员。

如果你的换岗是由于上述原因2或3，则你可能会在更好的条件下工作。

在离开第一家公司一年之前，我决定转到另一个团队。几个团队请我加入，如果我能把自己分成多个部分，我会很高兴加入他们所有人。

当我加入新团队时，我觉得我的高级头衔不再合法。我不得不学习新的代码库、工具和实践。当然，学习新东西很棒，但我不再是团队的技术参考。不过，每当团队不得不为我以前的团队项目做出贡献时，我可以以更有效的方式帮助他们。随着时间的推移，“不配拥有我的头衔”的感觉逐渐消失，随着我掌握的技能越来越多，我变得更好。

也就是说，我认为频繁更换团队是不好的。我在第一个团队呆了五年多，然后转到新团队一年，最终由于与这个新团队无关的原因离开了公司。

如果你觉得自己的情况符合这三个原因中的一个，我会建议你考虑更换，但前提是你至少在当前团队呆满一年。我认为一年是合理的时间来判断你是否属于当前团队。如果你无法等待一整年，那么这意味着情况相当严重，我建议你让经理参与进来，和/或他们的经理来解决紧急情况。

2.6 写博文

这本应该只是“写”，但感觉太短了。写作是开发者应该具备的最重要技能之一。我们的日常工作中涉及大量写作:代码、消息、电子邮件、文档、RFC、会议记录、事故事后总结等。

书面交流是与人们异步交流的最佳方式之一。他们可以在适当的时候阅读你的消息，而不会在任务中间被打断，可以专注于手头的工作。当然，在某些情况下，同步交流是更好的交流方式，即视频通话、现场会议等，以解决某些紧迫情况或消除歧义和误解。但在我的经验中，相比每天谈话，开发人员更多地接触写作。

写博客文章有以下几个原因，很有意思:

• 熟能生巧。提高一项技能的唯一方法是通过练习。如果你不确定自己是否做正确，你可以寻求你认为在这方面做得很好的人的帮助，以便他们可以在这个主题上指导你。你也可以阅读相关的文档和博文。也就是说，最重要的事情是开始练习，即使你的第一篇文章有些缺陷。

• 它迫使你了解自己正在谈论的主题。这是真正学习事物的好方法——通过比平时更深入地研究某一特定主题。

• 它开发了你的个人品牌。对你的博客文章感兴趣的人越多，你获得的追随者就越多，你就越有影响力。

你可以在个人博客上写文章，也可以在公司博客上写文章。一开始为公司撰写是很好的，因为它已经有一批读者和关注者。但是，你在要谈论的主题上的自由度较低，因为公司可以选择。

不要指望第一次写博客文章就会流行。成为有影响力需要很长时间。你甚至可能永远不会达到那个时刻，这很正常。你应该为自己写作，以提高写作技巧并与社区分享你的发现。你不应该关心获得多少赞或关注者。是的，这种认可是极大的精神支持，但你的目标不应该是增加这些数字。你的目标应该始终是提高写作水平和分享知识。

我的写作之旅始于在第一家公司的工程博客上发表文章:网络浏览器中最准确的调度函数的方法。它甚至在JavaScript每周通讯中得到了提及，这感觉很棒。

然后，在2021年3月，我开始在Dev.to上撰写博文，并且偶尔继续这样做。我还在HackerNoon上发表了一篇文章，但我真的不喜欢他们对标题的编辑，并且觉得Dev.to目前会是我的主要博客平台。

3 我希望以不同的方式做的事情

3.1 在向团队引入新事物时要小心

随着你的职级越来越高，这一点尤其如此，尽管初级开发人员也应该有能力向团队引入新事物，无论是库、语言、范例、共同工作方式等。作为初级开发人员，你会更容易受到团队中高级成员的质疑。但是，你的职级越高，说服别人就越容易，尤其是初级开发人员。

在第一家公司，在转到另一个团队几个月前，我处于一个可以对代码库提出...雄心勃勃的变更的位置。那时，我已经学习函数式编程范式两三年了，我相信它的优点。

在几个月的时间里，我向两支队伍(包括我的队伍)介绍了函数概念。为了记录在案，这些演示发生在我向代码库引入重大更改之前。

我认为这些培训课程已经足以说服人们采用这种新范例。当时:人们点头表示同意。他们理解新的概念、优缺点，以及我们可以用来改进项目的东西。

在某种程度上，在这些演示之后，我们看到了一个机会:

这是夏天开始时，所以商业活动会在几个月内却是相当缓慢。

在上半年，我们在一个最古老的系统中遇到了一些bug并不得不使用肮脏的变通方法。

使用函数概念和TypeScript(简称TS)的类型，我们可以大大改进该系统的可测试性和开发人员体验。那个旧系统最初是作为TS的早期版本开发的，没有提供很好的类型功能。

换句话说，这是重构的大好时机!我向团队展示了一个概念验证，使用函数和类型级编程与TS，以极大地改善该系统。我们都确信其益处，并决定继续生产准备好的实现。我负责创建任务、计划哪些可以并行完成等。我定期发布更新到Slack频道，以便利益相关者可以跟踪进度。

我将该系统的v2开发为我们自己代码库中的库，使其成为一个独立的模块，我们可以在其中对我们能想到的每种边缘情况进行单元测试，因为副作用终于在控制之下。尽管引入了大量新的概念、函数和代码更改，但每个人都很好。我在代码审查时得到批准。

我深受fp-ts库的启发，它具有与“常规JavaScript”不同的编码方式，有些人可能会说。由于我不会在这里提及的限制，我们无法简单地将库导入代码库中，所以我必须重新引入该库的一些函数和数据类型，并做了少量调整。我分享了有关这些更改的更多演示，并获得了积极的反馈。

没有反对意见导致我继续深入兔子洞。

一旦新的系统完成并经过测试，我们就必须替换散布在代码库各处的旧系统。它在很多地方被使用，所以从旧系统迁移到新系统证明非常麻烦。

我从未在生活中如此过度工作。我喜欢重构旧代码以获得我认为是更好版本，所以我没有计算时间。两个月内，我一天必须工作大约十小时，包括周末。

工作完成后，我休息了两周(它们早就计划好了)。当我离开时，团队不幸遇到一个相当重要的事故。他们在确定根本原因和找到解决方案时遇到了困难。这个问题位于新系统内部，它与代码库的其余部分看起来不一样。团队不熟悉它，因为基本上只有我开发了它。

在演示期间，人们理解了这些新工具和实践，并同意进行更改。但是，一旦他们独自处于所有这些新事物中，他们就ifihtfully感到不知所措。

演示是一回事，但如果你不实践刚学到的知识，你最终会忘记它。此外，分开介绍每个概念与一起使用它们是不一样的。它为本已难以学习的主题增加了复杂性。

长话短说，我向团队介绍了许多新概念，而当我演示时他们表示赞同，但我带给项目的变化极大地损害了他们在我不在时解决关键问题的能力。

当我回来并了解了这起事故时，我提出与他们分享更多演示，以便他们更熟悉新代码。

事实上，我本不该一头扎进兔子洞。这不是一个务实的解决方案。类型改进很棒，但整个新的功能系统是一个错误。

你不应该仅因为对这些更改感到舒适而向团队带来重要更改。你必须牢记乘客因素。我以为我会在那个团队呆得足够长，以至于每个人最终都会熟悉新代码，我可以渐进地教给他们。

但在这些事件发生几个月后，我加入了另一个团队。回想起来，在离开他们几个月之前就扔下这个难以维护的模块，并几乎因为它而身心俱疲，我感到内疚。

无论你是独立撰稿人还是经理，如果高级团队成员引入像这些改变，我强烈建议你确实质疑他们的提议。我确信在我的情况下可以找到更好的权衡。

如果你与我处于同样的位置，我建议你三思而行。这真的是一个务实的解决方案吗?你确定范围定义良好且已经识别兔子洞吗?你是为了团队的利益还是因为你喜欢它而这样做?在你不在场时，团队会对此感到舒适吗?

3.2 不要在团队面前让情绪占据主导

我曾有过这样的时刻:在会议上，管理人员或同事与团队分享的任何东西都让我强烈反对。我让房间里的每个人都知道这令我烦恼，从而公开开始了一场“冲突”。

我想向我的同龄人展示公开反对别人决定是可以的。但是，这种行为是不健康的:

当冲突变得明显时，人们可能会感到不舒服。让他们处于这种境地是不公平的。

这可能在团队内造成分裂，一些人同意A的观点，其他人同意B的观点。团队必须保持一致才能提高效率。

一般来说，这显示出某种自我控制和纪律的缺乏，以及在思考情况时无法退后一步的某种能力。

我并不是说控制我们的情绪很容易。毕竟，我们是人，不是机器。但重要的是要对我们的同龄人表示尊重，避免扰乱会议的进行。

在我看来，正确的做法是等待会议结束，然后立即:

在1对1会议中与对方谈话。

与你的经理讨论该情况，并找到解决的方法。

触发这个1对1的时间必须紧随让你感到这种情绪冲动的会议之后。时间过去越久，情况越糟。

依我看，与对方交谈总是有助于改善情况。交流就是关键。没有社交互动，我们在公司(或个人生活)中走不远。

在招聘市场里探个底

当我作为实习生加入第一家公司时，我与未来的经理进行了30分钟的面试。就这样。我进行了一次快速的“文化匹配”面试，并被录取了。

之后，我在招聘市场上没有立足之地，直到7年半后。我唯一且简短的招聘市场经历明显与我即将面对的完全不同。拥有近八年经验申请高级职位的招聘过程肯定不仅仅由“30分钟的行为面试”组成。

在阅读历史上最激烈的技术工作市场后，我觉得我已经准备好尝试了。我更新了LinkedIn个人资料，然后将自己设置为“正在寻找工作”。

我感到不知所措。从2021年9月到10月底，我每天必须处理5到10个工作邀约。我不得不请假来解决这种情况，并花费相当多的周末时间来处理它。

一开始，我能够回复每个招聘人员的消息。但当我:

不得不工作一整天，因为我当时还在现任公司工作。

正在搬到另一座城市，这对我来说相当压力重重。

正在与几家公司进行招聘流程。

继续收到新的工作邀约。

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

最后，我写了自己的模板消息，其中包含我对下一份工作的愿望。我尽可能多地提供了细节:公司规模、工程文化、远程工作、薪酬、技术挑战等。但尽管如此，我无法跟上所有消息。

对于那时联系我的所有招聘人员，以及由于不知所措而无法回复的招聘人员，我感到抱歉。我不知所措。

但处理LinkedIn消息不是最困难的部分。事实上，面试才是最耗心的部分。由于我从未有过DSA(数据结构和算法)的训练，所以我从未感受到需要改变公司的需求。

我主要在leecode上进行训练，还购买了一些书籍以提供帮助:

• Gayle Laakmann McDowell的《破解编程面试》。

• 亚历克斯·许的《系统设计面试第一卷》。

此外，我不得不详细介绍我职业生涯中开展的一些最有影响力的项目。这就是前面我们提到的工作日志可能非常有趣的资产之处。

一旦我最后接受了一份报价，我就向经理递交了辞呈，我的新工作提供了大约25%的基本工资增加。还包括额外的补偿，总体上对我的情况有更好的员工福利(远程工作)。

我建议你时不时进行面试的原因如下:

你会在过程中获得一些经验，所以当你最终加入新公司时，你不会感到不知所措。

你可以查看自己在市场上的价值，并有 潜在地要求你目前的公司进行某些薪酬调整。如果你能获得工作报价，这意味着它将帮助你获得认为自己应得的东西。

在第一家公司，我得到了很好的年薪增加(年增长7%至10%)，除了最后一年。尽管对我在最后一年获得的没有满意，但我还是认为下一年我会获得更好的加薪。这一刻从未到来，因为我在它发生之前就辞职了。

由于我在该公司的大部分职业生涯中获得了很好的加薪，所以我从未感觉有必要查看自己在招聘市场上的价值。我希望我早点这样做。这不一定意味着我会提前离开公司，但至少我会得到一些经验，我还可以要求调整薪资而不是加薪。

请不要误会我的意思:获得10%的加薪很棒。但如果你的工资比市场告诉你的价值低15%至20%，那么10%的加薪还不够。你怎么知道自己是否拥有应得的薪酬?通过亲身体验那个市场。此外，通过与那些自己体验过市场的前同事保持联系。

面试并不会强迫你离开公司。你可以在留任当前公司的同时进行数十次面试，只要你不以面试代替工作。这就是为什么我不得不请假，并且不得不在清晨和午休时间进行面试。

4 结束思考

首先，非常感谢你读到这里!我希望这篇文章对你有用。

我想你已经注意到，所有这些建议实际上都与软技能而非技术技能相关。也许我会写另一篇更关注技术技能或硬技能的文章。如果你对此类内容感兴趣，请告诉我。

我想与你分享的最后一件事:与一些启发你的前同事保持联系，尤其是你认为他们出色完成工作的人。他们是你敬仰的人，因为根据你的标准，他们做得很出色。他们可能是出色的经理，也可能是有影响力的技术领导者，你非常欣赏他们。这很重要，因为他们将帮助你成长并成为更好的开发人员。他们甚至可能说服你加入他们的公司/团队，只要频率合理就很健康。每个人都应该建立一个帮助他们成为更优秀人士的网络。

如果你有机会尝试这些建议，并且对你有效，请分享你的经验。我真的很想了解这些建议的反馈，并看看它们是否可以应用于我自己情况之外的其他情况。

作者：场长

原文：

https://betterprogramming.pub/advices-from-a-software-engineer-with-8-years-of-experience-8df5111d4d55