软体工程师如何在职涯持续成长?
2024年12月20日
先前我们谈了《工程师的职涯路径概览》 ，接着在这一篇文章中，我们会延续这个话题，并且进一步谈，如何在工程师的职涯持续成长。
具体来说，这篇文章会分享三个可以立即开始行动的要点，推荐读者们可以把这篇提到的点，当成一个检查清单 (checklist)，可以看看有哪些是自己目前没有主动去做的。如果没有的话，推荐可以实际一试。
主动寻求回馈
如果想要加速自己的职涯发展，最有效的方法之一，是主动寻求回馈。多数的人都很乐意给回馈，协助你成长。然而，很多时候阻止别人给回馈的原因是「担心因为给了回馈，而破坏了彼此之间的关系」。要能避免这点，你需要主动让别人知道「你愿意接受他人的回馈」。
要主动寻求回馈，需要谨记以下要点：
- 主动跟别人提说「希望你能给我 XX 面向的回馈，协助我在这方面能持续成长」
- 在别人给回馈后，不要试图争辩，感谢对方，然后思考如何透过这些回馈来改善自己
- 如果不解对方为什么给某个回馈，可以进一步询问具体案例，问说「是因为在什么具体的案例下，我做了 XXX，让你觉得我在 OOO 方面可以更优化?」
如果能做到上面这三点，会更容易获得能协助自己成长的回馈。不过有些时候，你寻求回馈的人，可能会说你做得很棒，所以他们没有特别的回馈能给你。在这种状况，也推荐进一步询问具体例子，来了解为什么对方觉得你做的很好。这么做可以帮助你更了解自己的优势，也会对自我了解有帮助。
守备范围要越来越大
除了主动寻求回馈，随着职涯持续发展，要看得越广，让自己的守备范围越来越大。
以开发 API 来说，资深工程师就不能只看自己开发的 API，而是要问自己对现有产品的 API 整体体系了解多少? 是否能有方法来改善整体的 API 开发效率、改善 API 运行时效能?
更进一步说，成为资深工程师后，在看待 API 时，就不能只看 API 本身，而是要进一步去思考架构面、底层获取资料的东西。
守备范围不局限在开发上，在团队的流程优化，或者是在非开发的技术任务 (例如程式码审查)，都可以持续挑战更大的范围。举例来说，原本假如你只有帮忙自己团队的程式码审查，可以试着开始帮上下游团队看程式码并给回馈，甚至帮组织中其他团队看程式码。
谈到守备范围，就不能不提「先做再说」的观念。不要等到自己被升到下一个职级，才扩大自己的守备范围。在多数软体公司，这么做可能让你永远无法迈向下一个职级，因为软体公司的升迁往往是反过来的；你需要先展现你有能力做下一个职级的事，才有被法被往下一个职级升迁，而要展示你有能力的最好方法，就是实际去挑战下一个职级的事，借此证明自己有能力。
让自己能被取代
要在职涯中往下一个层级迈进，「让自己能被取代」是一个关键点。这是因为只有在自己原本做的事情，能有人取代来做之后，才会有时间去做其他更大守备范围的事。
一般来说，要让人能取代自己需要有几个要件，一个是要有系统地培训刚加入团队的人，让这些新成员能有能力取代你自己。另一个则是自己要愿意放手，适时把某部分正在做的事，让团队中的其他成员来做。
在 AI 时代，让自己能被取代的一个做法，是让 AI 取代自己。要做到这件事，最有效的方式，是透过把可重复利用的内容 (例如文件、影音) 转换成搭配 AI 的素材。
有了 AI 帮忙，团队将能省下更多时间成本。而要做好这件事，必须确保内容品质高，才不会出现低品质的输入造成低品质的输出 (俗称 garbage in and garbage out)。
当谈到让自己被取代，有些人可能会抗拒，特别是提到培育其他人时，会觉得自的「关键技术」要好好抓住，不能让别人学会，不然就失去竞争力。
这种固定思维 (fixed mindset) 反而会导致自己无法往下个职级迈进。事实上，在网路时代如果有心想学，透过网路资源几乎没有什么软体相关技术是学不到的；失去竞争力不会是因为分享知识与技术给别人，而是自己没有持续成长。
退一步来说，软体工程师的工作很看重团队，因为大型软体几乎很难凭一己之力完成，因此即使有什么独门技术，最终转换为程式码，仍需要有团队其他人协助审查给回馈，这也是为什么多数公司内的程式码，几乎设定上是每个人都看得到，没什么在刻意隐藏，有心的话人人可以去学，不会真的有什么独门技术可言。
现实中更常遇到的问题，反而会是东西在那边，但团队中的其他人不愿意去学 (或说学不动了)；因此想成为资深工程师，反而不是该担心自己的独门技术力被学走，更多是在烦恼如何把团队的学习文化建立起来，让初阶工程师更愿意去学习，然后能取代资深工程师在做的事。
阅读更多
如果你对「如何在工程师的职涯持续成长」这主题感兴趣，我们在 E+ 有更深入的讨论。有兴趣的读者，欢迎加入 E+ 成长计划。
本文为 E+ 成长计划的深度内容，截取段落开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本 (点此了解 E+ 的详细介绍)。