ExplainThis 全端開發雙週報 #74 如何成為更有影響力的工程師?
如何成為更有影響力的工程師?
嗨～歡迎閱讀第 74 期 ExplainThis 全端開發雙週報！
農曆年假一轉眼就過去了，希望讀者們都有趁著連假期間，好好休息、重新蓄積能量。
許多人在年後都有換工作的規劃，如果你也有意換工作，可以參考我們先前製作的《軟體工程師求職全攻略》線上課程 (連結)，只要加入 E+ 成長計畫即可觀看 (連結)。
除了線上課程外，在 E+ 也有提供履歷修改回饋的頻道，有用過的讀者都給予相當好的評價；在頻道中的履歷，我們都會給回饋直到改好為止。
以上，接著讓我們進到本期的主題文吧！
如何成為更有影響力的工程師?
前陣子收到讀者詢問，假如平常做的都是一些小事，難有影響力，該怎麼辦? 例如前端工程師會焦慮自己總是在切版，切了半年一年感覺都沒有在進步；或者後端工程師會焦慮，自己總是在開發只做 CRUD 的 API，開發了半年一年仍在原地踏步。
沒有進步感可能會讓人擔心，不知道該如何升上資深，又或者未來想換工作時，會沒有太多內容可以寫在履歷上面。因此在這篇文章中，我們會來聊聊如何從小事開始，往成為更有影響力的工程師邁進。
推薦大家可以把這篇文章提到的點，當成檢視清單，並以此來自我檢核。如果有目前還沒有做到的，可以進一步設定目標來改善。
追求影響力前先追求可靠
如同先前在 追求高效前，先追求做好 一文談到的，追求高效之前先把事做好，類似的道理也適用在追求影響力，在追求影響力之前，推薦先追求成為一名可靠的工程師。因為只有當成為可靠，才會讓人建立對你的信任，進而願意交託影響力更大的事情給你。
如何判斷自己是否做到可靠?
你可能會問，什麼樣的工程師是可靠的工程師?
推薦可以用以下幾個指標來自我衡量
交付品質高不高：寫的程式碼是否高品質? 在提交給 QA 測試時，是否能確保不會漏洞百出、充滿 bug?
沒有踩不該踩的底線：在軟體工程的領域有很多底線是不該踩的，舉例來說，在 如何把關好上線流程? 一文談到的上線時該遵守的規範，如果你一時偷懶、求快，而沒有遵守該走的流程，這時若出意外了，然後發現是因為你沒有照該走的流程，這對於信任的傷害會非常大。
給的承諾是否兌現：如果在估時的階段答應能交付，在實際時限到了後，是否如期交付? 答應做的事是否都有做到? 承諾必達是建立信任的根基，假如今天答應要做的事情都沒有做到，一次兩次後，會逐漸讓別人失去對你的信任。
該告知的都有告知：在團隊合作時，如果有任何改動，是否確保所有合作對象都有收到通知? 是只有告知，還是確保對方有接收到?
是否有先預判未來狀況：當做一件事情時，是否有多想未來可能會有的不同狀況? 還是每次都是東補一個漏洞、西補一個漏洞?
很多人會覺得自己在工作上，都做類似的事情，卻沒有去仔細檢視自己是否把事情做到可靠。當你能做到足夠可靠，讓人相信你、對你放心，會更容易去爭取進階的事情來做。
不要成為 0.1x 工程師
上面談到這些檢核自己是否可靠的指標，其實也是在衡量自己是否是 0.1x 工程師。多數人可能很常聽到業界有所謂的 10x 工程師，那些人比起其他人有 10 倍的產出，所以被稱為 10x。
但事實上，在光譜的另一個端點，有所謂的 0.1x 工程師，這類工程師不僅沒有做到自己該有的產出，還反倒讓團隊整體產出往下掉，導致團隊有了這類工程師後，不僅沒有加乘，反而產出變 0.1 倍。
之所以會這樣，是因為當今天某個工程師出的包，影響往往不會只是自己，而會是整個團隊。以上面提到的「交付品質不高」，如果因為這點導致出錯，導致線上已經部署的東西要回滾，這後續將導致要發一個新的 PR，所以團隊其他人要抽出時間幫忙審查，進而導致他們能做別的事情的時間減少，這就會讓團隊的整體產出下降。
因此，除了檢視自己是否可靠，反面的角度來看，請盡可能避免成為 0.1x 工程師。
同一個問題，有不同影響力的解法
前一段落談到，要爭取更進階的事情來做，需要先在當前的負責項目中，做到可靠讓人信任。然而，事實上很多時候，同樣一個問題，不同的解決方法，可能帶來不同的影響力。換句話說，你可能不需去爭取新的事情，而是可以從已經在做的事情開始，然後切入不同的角度，藉此來提高自己的影響力。
舉例來說，假如今天收到某個監控警報，得知某個新功能上線後，效能沒有達到團隊在效能面設定的標準。這時可能有以下幾個不同的反應：
第一層次：看到相關警報後，像是當沒看到一樣略過，心裡想不要被其他人注意到就好
第二層次：看到警報後，花了一點時間找原因，然後順手解決掉問題
第三層次：第一時間跟團隊告知，然後解決問題，解決完後再次跟團隊同步
第四層次：第一時間跟團隊同步、解決問題，然後寫下文件與團隊分享
第五層次：除了第四種做到的事外，還進一步思考目前系統中，有沒有可能有其他類似的潛在問題，並全盤檢查是否有造成系統性問題的根因
第六層次：除了第五種做到的事外，還進一步思考為何最初會有這問題、可以如何根治，並帶團隊一同優化流程或寫程式的實作方式，確保未來不會出現類似問題
可以看到，同樣一個問題，可以有多種不同層次的行為，這些行為能夠帶來的影響力也不同。當你開始覺得自己平常做的事情，都已經是自己熟悉的，覺得缺乏挑戰與成長，不妨可以試著往下一個層次的行為挑戰。以下我們逐一來解說如何做到不同層次。
閱讀更多
如果對於各個層次詳細的講解感興趣， 我們在 E+ 成長計畫的主題文，有完整的解析與說明，歡迎加入後閱讀 (連結)。
本期推薦
上個月 Alex Honnold 不帶任何裝備徒手爬上台北 101 大樓的最高點，在全球掀起一陣討論。身為軟體工程師，在看直播流手汗的同時，不免好奇「Netflix 的直播背後是如何撐起全球觀眾同時收看」這個問題，我們寫了閱讀官方技術部落格後的心得 (連結)。
Claude 團隊聲稱 Claude Code 現在都是由 Claude 模型自己寫的，既然 AI 都能寫所有程式碼了，為什麼還要用 Electron 寫? 在《Why is Claude and Electron App》探討了這個問題 (連結)，我們也寫了相關摘要 (連結)
延伸上一點，最近社群社群中有「如果 Claude Code 已經能 100% 取代寫程式這部分，為什麼 Anthropic 目前還有超過百個工程相關的職缺?」相關的討論，Claude Code 作者回覆在這個背景下，優秀的工程師比以往任何時候都更加重要 (連結)
上週 Supabase 出了一個事故，導致所有 us-east-2 的客戶全都受影響；事故持續數小時，很多人的產品因為這個事故 (連結)，甚至無法登入使用，在推特上一堆人叫苦連天。這個事故進一步引發了 Supabase 的遷出潮，這也說明穩定與可靠，仍是 AI 時代最根本的軟體核心 (連結)。
很多公司會透過 Dependabot 來自動更新程式碼庫中依賴的套件，但《Turn Dependabot Off》 一文提出不該繼續用 Dependabot，而是該用其他替代方式的觀點 (連結)
HuggingFace 共同創辦人上週分享了自己對軟體開發觀察，並預測了幾項 AI 會對軟體生態帶來的改變 (連結)
在使用 AI 代理時，讓 AI 代理能夠驗證自己生成的程式碼 (例如寫完程式碼後跑 linting 或 testing)，會對於整體的產出品質有幫助。因此，用跑更快的工具，能加速 AI 代理的驗證迴圈。Christoph Nakazawa 彙整的 JavaScript 工具清單 (連結)，如果你在的團隊，還沒有換成這類工具，推薦可以投資一些時間來遷移
文末彩蛋
知名開源專案 Ghostty 作者 Mitchell Hashimoto 前前陣子分享，他在逛某間店時，看到有店員在滑手機，這讓他感到非常震驚。他提到他爸爸常說：「永遠都有事情可以做」。沒客人的時可以去掃地，掃乾淨了可以去擦機器。機器乾淨了可以去整理庫存，整理好了可以再把環境清更乾淨。
這讓人想到在日本旅遊時，遊覽車司機在客人下車玩後，會把握時間把車內車外都清潔乾淨；比起那些會在等乘客時待在車上滑手機，或者成群結隊吸煙吃檳榔的司機，日本的司機會把握每個時刻讓車子能有更好的狀態。
如同這一期的主題文談到的，做一件事情有很多種切入角度，如果願意持續精進、主動往下一個階段挑戰，在職涯上自然能夠累積出更好的成果。