最近我又遇到了一個只要在團隊裏累積了一定資歷，就會出現的困境：
每天都在審查別人的 PR，但同時自己的任務進度又趕不上
回想起大概 6 年前，我也經歷過一樣的處境。
當時我在該公司待了 3 年，在組裏已經算是比較資深的了，其他成員不是只有 1-2 年經驗，就是新畢業生。
很自然地，我就變成了每個 PR 的預設審查員 (當時公司還不是用 PR，而是用 SVN 直接 Commit，然後我打開 Commit 來看改動，不過這是題外話)，但同時，我手頭上也有幾個已經延期了幾次的任務要趕。
在敏捷開發 (Sprint) 的節奏下，為了達到所謂的每個 Sprint 都要有產出的目標，主管很多時候都會要求我先去看別人的 PR，確保團隊有一定產出，然後再埋頭自己的工作。
然而，別人的 PR 總是一波未平一波又起，根本沒有停下來的一天。
到了現在這個 AI 時代，情況有點改變但似乎並沒有往好的方向發展。難聽點講句，對於一些不太懂用 AI、對程式碼認識不深，而且責任感較低的工程師 (雖然不多，但總會遇到 1-2 個)，AI 只是加快了他們產出「垃圾程式碼」的速度，然後拍拍屁股攤在那邊，等著資深工程師來幫忙擦屁股、抓 Bug。
面對這種到底該花時間提升隊友 (Upskill peers)，還是自己動手做更多的兩難，最近我又再次感受到那種無力感，但這次我決定不再像之前那樣處理了。
Burnout
其實在我接近 10 年的職業生涯中，我已經不止一次遇到這種情況，但我的性格很容易令我重複過往的錯誤，把所有責任往自己身上攬，然後 Burnout。
記憶最深刻的一次 (有看我電子報的可能已經聽過幾次)，就是在一家公司接下了建立一支後端開發團隊的任務。小組成員大部份都是 2 年經驗以下的工程師，或者是新畢業生，反正是不能一入職就上手那種。但偏偏我們負責的專案在時間上有極大的壓力，這令我非常頭痛：
如果我親手寫程式碼，絕對比他們快至少一倍，也許捱著加班一段時間就能趕上死線。但這樣做我就沒時間帶他們，他們閒著沒事幹，沒機會學習、進步，而我就一個人忙到懷疑人生。
另一個選擇是花時間教他們，起初效率一定慢，甚至要冒著因未能定期交付而被炒魷魚的風險，但幸運的話幾個月就能見到成效，他們能獨當一面處理開發任務，提升整體產出 (美好的理想💭)。
而我是怎樣做到自己 Burnout 的呢？
就是白天帶他們，下班後等大家都走了，我再加班寫程式趕進度。
(現在回想起都覺得自己蠢)
最辛苦的是頭半年，幾乎星期一至五朝九晚九都在工作，週末除了必要的事情外，2 天的假期加起來最少花了 10 小時在工作，一週工作接近 70 小時，這樣做才能勉勉強強追得上專案的進度。
之後，我慢慢看到投資在他們身上的回報。專案團隊過來問問題他們知道在哪可以找到資料、UI/UX 團隊把設計交給他們也知道該問什麼問題 (我們不是負責前端所以問題集中在資料結構上)、新功能要做時間估算就算我不在也能說得似模似樣。
簡短來說，就是我能開始把自己身上的工作，下放到他們身上了。
8 個月左右，我總算在辦公時間拿回了寫程式碼的自主權 (感動😭)，雖然我下班後還是自虐地思考引入新工具來改善工作流程，建了 CD (Continuous Delivery) 管道處理我們負責的專案的部署工作，但感覺很充實。
不過，這也不是沒有代價的，大約一年後，我的身體和精神就徹底 Burnout 了。
舊病復發前的警鐘
那次 Burnout 對我的影響很深，亦形成了一點心理陰影，但即使如此，這陣子我面對著 PR 海嘯，和專案死線的夾擊，我第一時間想到的，竟然還是上班時間幫大家看 PR，下班時間再加班做自己的任務🤦🏻♂️
這可能是我 (或部份工程師) 的奴性？出現問題時有時候只想默默地往自己身上攬。
這次我想了幾天，才猛然回想起當年那累到不想再上班的恐懼，明白自己不能重蹈覆轍，這次要做點不一樣的。
比以往好的是，以前我只能自己一個人想解決辦法，或者跟同事/主管聊，現在有了 AI，跟它聊了一會草擬了以下的計劃：
第一步：建立 PR 的同行評審 (Peer-Review)
根據我最近一個月的觀察，他們現時對於 PR Review 的流程很多時候長這樣：
先處理 Copilot 所提出的問題
等候我的評審，處理好後就 Merge
就算在 GitHub 設定上不是直接把 PR 指派給我，是整個團隊，但我感覺他們已經在心裏預設了我是 PR 審核人，只要有我的綠色勾號 (批准) 就能交貨。
雖然我很高興能得到他們的信任，但長久下來這不是辦法，坦白說我以前就是透過 PR 看別人的程式碼才學到這麼多，如果我只是唯一的審核人那等於在剝奪他們的成長機會。
所以我將跟主管提出以後大家提交 PR 後，先不要直接指派任務給我，先在同層或經驗差不多的同事之間進行至少 1-2 輪的同行評審。
先由他們互相去挑出那些低級錯誤，像是在別的環境就出錯誤、部份需求未達成這類，修改得差不多了才到資深工程師來做最終的評審。
而且，假如 PR 的改動就算出錯也不會影響大局、不會讓搞垮生產環境的話，就由得他們 Merge，但也明確地表示他們需要為自己寫的程式碼負責，雖然 PR 是整個團隊的產出，但出事了依然要協助排查和處理。
第二步：開發前問題清單
不管是剛畢業的新人還是剛入職的工程師，普遍都有一個傾向 (坦白說我以前也是這樣)：
接到任務後，就迫不及待想用最快的速度把程式碼寫完交貨
加上我們組會為任務估計故事點 (Story Points)，在很多人眼中，效率就是在一個 Sprint 中完成越多的故事點，從而證明自己的能力。
但大家都知道 (但同時很容易被忽略)，盲目追求速度通常只會換來品質上的取捨。我跟現任主管有聊過這問題，他期望新人透過這些任務來熟悉團隊的開發模式、學習如何跟其他團隊合作，例如團隊的程式碼風格 (Code Convention)、遇到需求上的問題時能釐清則釐清、實在不行才做預設等等。
而這學習過程通常會拖慢任務進度，他亦表示這不重要，因為重要或時間緊逼的任務通常不會交給他們。
因此我提議新人在開始開發任務前要先在 Jira 上回答幾條問題：
有沒有可參考的程式碼和設計模式？
這開發任務需要怎樣的 Breakdown？
子任務之間有沒有依賴性 (Dependency)？
應該怎樣安排子任務的先後次序才能避免整體進度卡住？
這些在很多新人眼中都只是「軟實力」，甚至是繁瑣的行政流程，但其實它們能讓工程師在動手前進行一次全局的思考，把解決問題前會遇到的困難找出來，是真正的硬技能，尤其現在有了 AI，弄清楚這些問題能省不少 Token。
我將在下次跟主管的 1:1 裏提出這些建議，希望能幫自己、也能幫其他組員成長，到時候如果有什麼進展或主管的反饋，我再來跟大家更新。
職場小挑戰
除了跟主管或團隊直說之後，老實說有時候我在收到 PR 審查邀請、或 DM 問問題時，我會啟動「假裝很忙」模式，有時候能逼使他們自己找辦法解決，是種放手讓他們自己想的方式。
如果你組裏也有資歷較淺的同事，你可以在下次對方找你問問題時，嘗試先等個 1-2 小時才回覆，或者說手頭上有個趕死線的任務，先找其他同事幫忙或再研究一下。
根據我的經驗，這方法偶爾有效，對方大概有 50% 機會能自己多花點時間找到答案，但當然這方式我不建議常用，因為可能會影響自己在團隊裏的形象 (畢竟自己任務的進度和緊急性大家總會知道)，所以偶爾用一下就好了😜
給個參考，我之前的做法是，如果新進的工程師給我那種超大的 PR，我通常會跟他們說：
1. 可以把這個 PR 做 breakdown 嗎？
2. 如果不行的話，可以 book 一個 meeting，直接 walk me through。
他們應該要能夠自己去解釋。如果他們能 walk me through，我看的速度也會更快，他們也會覺得程式碼的責任是在自己身上。而且如果他們要能夠自己 walk through 的話，也會重新看自己的程式，可能可以降低更多低級錯誤。