如何成为更有影响力的工程师?

前阵子收到读者询问，假如平常做的都是一些小事，难有影响力，该怎么办? 例如前端工程师会焦虑自己总是在切版，切了半年一年感觉都没有在进步；或者后端工程师会焦虑，自己总是在开发只做 CRUD 的 API，开发了半年一年仍在原地踏步。

没有进步感可能会让人担心，不知道该如何升上资深，又或者未来想换工作时，会没有太多内容可以写在履历上面。因此在这篇文章中，我们会来聊聊如何从小事开始，往成为更有影响力的工程师迈进。

推荐大家可以把这篇文章提到的点，当成检视清单，并以此来自我检核。如果有目前还没有做到的，可以进一步设定目标来改善。

追求影响力前先追求可靠

如同先前在 追求高效前，先追求做好 一文谈到的，追求高效之前先把事做好，类似的道理也适用在追求影响力，在追求影响力之前，推荐先追求成为一名可靠的工程师。因为只有当成为可靠，才会让人建立对你的信任，进而愿意交託影响力更大的事情给你。

如何判断自己是否做到可靠?

你可能会问，什么样的工程师是可靠的工程师?

推荐可以用以下几个指标来自我衡量

交付品质高不高：写的程序代码是否高品质? 在提交给 QA 测试时，是否能确保不会漏洞百出、充满 bug?
没有踩不该踩的底线：在软件工程的领域有很多底线是不该踩的，举例来说，在 如何把关好上线流程? 一文谈到的上线时该遵守的规范，如果你一时偷懒、求快，而没有遵守该走的流程，这时若出意外了，然后发现是因为你没有照该走的流程，这对于信任的伤害会非常大。
给的承诺是否兑现：如果在估时的阶段答应能交付，在实际时限到了后，是否如期交付? 答应做的事是否都有做到? 承诺必达是建立信任的根基，假如今天答应要做的事情都没有做到，一次两次后，会逐渐让别人失去对你的信任。
该告知的都有告知：在团队合作时，如果有任何改动，是否确保所有合作对象都有收到通知? 是只有告知，还是确保对方有接收到?
是否有先预判未来状况：当做一件事情时，是否有多想未来可能会有的不同状况? 还是每次都是东补一个漏洞、西补一个漏洞?

很多人会觉得自己在工作上，都做类似的事情，却没有去仔细检视自己是否把事情做到可靠。当你能做到足够可靠，让人相信你、对你放心，会更容易去争取进阶的事情来做。

不要成为 0.1x 工程师

上面谈到这些检核自己是否可靠的指标，其实也是在衡量自己是否是 0.1x 工程师。多数人可能很常听到业界有所谓的 10x 工程师，那些人比起其他人有 10 倍的产出，所以被称为 10x。

但事实上，在光谱的另一个端点，有所谓的 0.1x 工程师，这类工程师不仅没有做到自己该有的产出，还反倒让团队整体产出往下掉，导致团队有了这类工程师后，不仅没有加乘，反而产出变 0.1 倍。

之所以会这样，是因为当今天某个工程师出的包，影响往往不会只是自己，而会是整个团队。以上面提到的「交付品质不高」，如果因为这点导致出错，导致线上已经部署的东西要回滚，这后续将导致要发一个新的 PR，所以团队其他人要抽出时间帮忙审查，进而导致他们能做别的事情的时间减少，这就会让团队的整体产出下降。

因此，除了检视自己是否可靠，反面的角度来看，请尽可能避免成为 0.1x 工程师。

同一个问题，有不同影响力的解法

前一段落谈到，要争取更进阶的事情来做，需要先在当前的负责项目中，做到可靠让人信任。然而，事实上很多时候，同样一个问题，不同的解决方法，可能带来不同的影响力。换句话说，你可能不需去争取新的事情，而是可以从已经在做的事情开始，然后切入不同的角度，藉此来提高自己的影响力。

举例来说，假如今天收到某个监控警报，得知某个新功能上线后，效能没有达到团队在效能面设定的标准。这时可能有以下几个不同的反应：

第一层次：看到相关警报后，像是当没看到一样略过，心里想不要被其他人注意到就好
第二层次：看到警报后，花了一点时间找原因，然后顺手解决掉问题
第三层次：第一时间跟团队告知，然后解决问题，解决完后再次跟团队同步
第四层次：第一时间跟团队同步、解决问题，然后写下文件与团队分享
第五层次：除了第四种做到的事外，还进一步思考目前系统中，有没有可能有其他类似的潜在问题，并全盘检查是否有造成系统性问题的根因
第六层次：除了第五种做到的事外，还进一步思考为何最初会有这问题、可以如何根治，并带团队一同优化流程或写程序的实作方式，确保未来不会出现类似问题

可以看到，同样一个问题，可以有多种不同层次的行为，这些行为能够带来的影响力也不同。当你开始觉得自己平常做的事情，都已经是自己熟悉的，觉得缺乏挑战与成长，不妨可以试着往下一个层次的行为挑战。以下我们逐一来解说如何做到不同层次。

第二层次：自我要求

从第一层次要进到第二层次，需要有自我要求，对于看到的问题，不会轻易放过。这种自我要求应该要贯彻在工作中的各个面向。举例来说，在为什么要 Code Review? 如何做 Code Review? 一文中，有谈到如果完成程序代码，要在 PR 的讯息中，写出改动的内容，如果你没有这种自我要求，且团队中没有其他人要求你这样做，很可能导致你一直用不完整的方式做事，久而久之成为习惯，这将难以持续成长。

第三层次：团队视角

从第二层次要进到第三层次，需要进一步有团队视角，需要看到自己以外的其他人。在现代软件开发工作中，多数都是以团队出发，因为单靠一个人，很难在短时间内完成一个复杂系统。因此，在做任何事情时「脑中有想到团队其他成员」会是很重要的。当发生问题时，解决后有同步到团队，就是多了团队视角的行为。

以上面谈到的程序代码审查 (code review) 为例，如果多思考团队这个角度，不自我要求可能会有更大的负面影响。例如你是初阶工程师，资深的人看到你的 PR 可能会觉得你做事不详尽；如果你是资深工程师，团队的初阶工程师看到，可能会觉得「团队中的资深开发者都这样做，那我这样做也没关系」，这会让团队的整体做事品质都下降，是需要避免的。