從 IC 到主管，再回到純 RD：一個後端工程師的自省與 DevOps/SRE 思考

這篇比較個人。我從基層工程師一路做到帶人主管，然後又選擇回到純粹的 RD。這條來回的路讓我對「工程師的下一步到底是什麼」有了一些跟主流敘事不太一樣的想法，寫下來，也算是給自己和同樣在思考的人一個交代。

升上主管，不是升級，是轉職

業界預設的「成長路徑」常常是：工程師做久了就該帶人、當主管。好像那是一種升級。但我自己走過才確定：那不是升級，是轉職。

當 IC（個人貢獻者）時，我的產出是程式碼、是把一個難題解掉的成就感。當主管後，我的產出變成「讓別人能產出」——排優先序、處理人的問題、開不完的會、對上對下的溝通。我寫 code 的時間從一天八小時掉到一週可能不到八小時。

這兩件事需要的能力幾乎不重疊。一個很會解 bug 的人，不會自動變成一個很會帶人的人。把優秀的 IC 推上管理職，然後讓他在不擅長也不享受的位置上痛苦，業界這樣浪費掉的好工程師太多了。

為什麼我選擇回來

當主管那段時間我學到很多——尤其是從更高的角度看事情：理解為什麼有些技術上「正確」的決定，在商業或團隊脈絡下行不通；理解溝通和信任比聰明更稀缺。這些我不後悔。

但我也越來越清楚，讓我真正有熱情、晚上會想多看一下的，還是技術本身。我享受把一個系統設計得乾淨、把一個效能問題追到根因的那種專注。坐在會議裡調解資源，不會給我那種感覺。

於是我做了一個在很多人眼中「往回走」的決定：回到第一線。現在我把帶人時學到的視角，帶回到 RD 的工作裡——這反而讓我成為一個更好的工程師。我會主動想商業目標、會把事情講給非技術的人聽、會考慮維護的人而不只是寫的人。

回來之後，我更認真看 DevOps 和 SRE

回到第一線後，我花更多時間在以前覺得「不是我負責」的東西上：部署、監控、可靠性。也就是 DevOps 和 SRE 的範疇。

當主管時我看的是「這個功能何時上線」；回來之後我更在意「上線之後它半夜會不會把我吵醒」。這個視角的轉變讓我相信：

• 能寫功能只是一半，能讓功能穩定運行才是完整的工程。一個會掛、難部署、出事查不到原因的系統，功能再多也是負債
• 監控和告警不是上線後才補的，是設計的一部分。一個系統「怎麼觀測」應該在寫它的時候就想好
• 自動化部署不是為了潮，是為了讓「改一行就能安全上線」變成日常，降低每次發布的恐懼
• SRE 那套用「錯誤預算」來平衡穩定性和開發速度的思路，其實是一種很成熟的工程哲學：承認系統不可能 100% 不出錯，然後理性地決定要花多少力氣在可靠性上

我現在會說，一個資深後端工程師如果完全不碰 DevOps/SRE，他對「系統」的理解是不完整的。寫得出來、跑得穩、出事修得快，這三件事是一體的。

工程師的下一步，不只有「當主管」

如果要把這些年的自省濃縮成一句想跟年輕工程師說的話：成長的方向不是只有一條向上的管理路。

• 你可以往深走，成為某個領域真正的專家（架構、效能、可靠性、安全）
• 你可以往廣走，成為能掌握整條鏈路、跨越前後端與維運的工程師
• 你也可以去帶人——但前提是你真的喜歡「成就別人」這件事，而不是因為那是「唯一看起來像進步」的選項

頭銜會變，潮流的技術也會一直換。但「把問題想清楚、把系統做扎實、誠實面對自己的不足」這些東西，是任何路線都帶得走的。

小結

我繞了一圈，從 IC 到主管再回到 RD，最大的收穫不是哪個位置比較好，而是想清楚自己要什麼。對我來說，那是技術的深度、系統的可靠、以及持續學習的樂趣。如果你也正在思考工程師的下一步，我的建議很簡單：別讓別人的路徑表決定你的方向，多寫、多想、多自省，答案會慢慢浮現。