軟體工程師職涯演化 | 從全能工程師到問題定義者

有天整理我的舊履歷，我突然意識到一件事：

那份文件，不只是我個人的工作紀錄。它幾乎像一部濃縮版的近代軟體工程演化史 (OMG 😱)。從 2000 年代初期自己架網站、改 HTML、接到伺服器燒掉了還要去機房重開機，一路走到現在帶領團隊審查第三方系統、砍掉四成雲端費用。

我是否一個人走過了整個產業在走的路？

但更諷刺的是什麼？

藉由這個歷史，回顧軟體工程師職涯，是因為自己發明了太強大的工具，才把「過去的自己」給淘汰的。

---

聽聽看 NotebookLM 幫我製作的 Podcast

---

「全能工程師」的時代：一人扛起所有事

如果你對 2000 年代的軟體工程有印象，大概記得一個很常見的場景：一個人、一台電腦、全包。

那時候的網頁工程師，其實就是校長兼撞鐘。

網站規劃由我來，介面設計由我來，後端邏輯由我來，資料庫也由我來，上線之後伺服器壞了，還是由我去機房解決。整個開發流程從頭到尾，我一個人就說得完。

這不是因為那個時代的工程師特別厲害，而是因為整個「架構」相對單純。

用一個比喻來說：那個年代的工程師，就像在街口開一台餐車的老闆。自己去市場採買，自己備料，自己炒菜，客人來了自己接單，收攤後還要自己修車。聽起來很辛苦，但還撐得住，因為客人也沒那麼多，菜色也沒那麼複雜。

但這樣的工作形態，很快就遇到了一堵高牆。

你有沒有想過：如果一個系統可以「一人包辦」，真正的限制是在「技術」還是「複雜度」？

手機、大數據，打碎了「一個人能搞定」的幻想

兩件事幾乎同時發生，把原本那套平衡給撞碎了。

第一件事是 2007 年的 iPhone。

螢幕變小了，觸控取代了鍵盤，網路延遲讓原本那種「把整頁排版好再丟過來」的做法完全失靈。使用者的瀏覽器突然不再只是一個被動接收的畫面，它開始要求即時反應、流暢動畫、跨裝置適配。前端的工作量爆炸性地成長，餐車的「外場」變得太複雜，大廚沒辦法一邊炒菜一邊招呼各式各樣的客人了。

前端工程師，就是這時候從原本的「網頁工程師」裡被拆出來的。

第二件事是數據量。

每個人口袋裡都有了手機，資料產生的速度呈指數成長。Google 和 Yahoo 最先感受到這個壓力。原本那種「把所有資料塞進一台超強的電腦」的做法完全行不通了，你沒辦法一直去買更大的機器，因為物理極限就在那裡。

於是，分散式系統誕生了。不用一台超級電腦，改用一萬台普通的機器協同運算。聽起來優雅，但背後帶來的架構複雜度，早就超出了一般網頁工程師的知識邊界。

大數據工程師，就這樣從分工的需求裡被創造出來了。

這個過程有一個很精準的工程概念可以描述：當單一節點的負荷超過上限，系統就必須走向「水平擴展」——用更多的分工取代單一的全能。 放到職涯的語言就是：當一個人的認知頻寬裝不下整個複雜度，分工就是唯一的出路。

工具越強大，工程師的眼界越往上移

有趣的地方來了。

2014 年前後，全端工程師的職稱突然變得非常流行。一個人，從資料庫一路做到使用者介面，聽起來是不是很像繞了一大圈，我似乎又回到最初那個「校長兼撞鐘」的起點？

不是的。這裡有個關鍵的差異。

2006 年的「全能」，是因為沒有更好的工具，你只能什麼都自己做。那時候的全能，靠的是忍耐和硬撐。

2014 年的「全端」，是因為工具變得太好用了，框架幫你封裝掉了大量的底層細節，雲端服務幫你解決了基礎設施的煩惱，你終於可以站在主控台前，用高層次的視角設計整個系統的資料流動方式。

差別不在於做的事情數量，而在於站的高度。

以餐車的比喻來說：以前是自己去菜市場採買、手工備料、現場炒菜；後來是站在中央廚房的主控台前，按幾個按鈕就能調動自動化的流程，從冷凍庫到出餐，一氣呵成。

我自己的履歷在這個時期，也有一個明顯的轉折。

2010 到 2013 年，我從單一功能的開發，逐漸擴展到企業伺服器的整體規劃。2014 年正式成為全端工程師，開始用 C# 與響應式設計 (響應式網頁設計 – 維基百科，自由的百科全書) 同時處理前後端。然後，從 2014 到 2021 年，我在同一間公司擔任系統工程師，做的事情已經不是「寫出某個功能」，而是負責系統架構設計與流程協調，我帶著整個團隊達到了專案按時交付率百分之百、系統故障率大幅降低的成績。

那個轉變不是某一天突然發生的，但我可以清楚感受到重心在移動。

從「我能寫出什麼」，變成「這個架構能不能長期撐住」。

這讓我想問你：在你現在的工作裡，你花最多時間做的事，是「執行」還是「設計」？你清楚這兩者的比例嗎？

AI 時代，最後那 10% 才是你真正的位置

2021 年之後，我竟然接下了一個讓很多工程師望而卻步的任務：

接手一套完全沒有說明文件的老舊系統，在不停機的狀況下，把它反向工程拆開來，重新整理資料結構，大幅縮短查詢回應時間，並且把維護成本砍掉三成。

那是一種很特別的工作狀態。我沒有地圖，只能一邊看著眼前的系統行為，一邊在腦袋裡重建整座城市的地下水道。

後來我把這套思維帶進了現在的工作。擔任開發副理之後，我帶領團隊審查第三方 App 的原始碼，提出數十項架構改善建議，讓系統崩潰率大幅降低、API 回應效能顯著提升，還把雲端費用直接砍了好幾成。

這些成績的背後，沒有什麼神奇的演算法。有的是多年累積的系統思維，讓我能看出哪個地方的設計在浪費資源，哪條路徑正在讓整個架構慢慢崩解。

現在，AI 能在幾秒內生成幾百行乾淨的程式碼。預測數據指出，在現在的 2026 年，AI 有能力獨立完成超過九成的程式撰寫工作。

那工程師要做什麼？

剩下的那 10%，是 AI 沒辦法替你回答的問題：這些程式碼，是要用來解決誰的問題？它真的解決了嗎？

會寫程式的 AI，只是大腦的外掛，就像計算機之於數學家，它讓你算得更快，但它不知道你為什麼要算這道題。

未來的工程師，不是被取代的人，而是那個決定要問哪個問題的人。

你的那 10%，是什麼？

從 2000 年代一人包辦的餐車老闆，到 2010 年代雲端分工時代的全端工程師，再到現在能重購整座城市管線系統的分析師。

回頭看，每一次角色的轉變，都不是因為原本的技能沒用了，而是因為工具強大到讓你可以站得更高，去看更大的事情。

那些早年扎實建立的技術底子，沒有消失。它們變成了一種語感，讓你能精準地感知系統哪裡在呻吟，哪裡快要斷裂。

這個趨勢，不只發生在軟體工程這個領域。

如果你現在所在的職業，AI 遲早會接手九成的執行工作，那麼留下來的那一成，那個真正需要你的部分，是什麼？

你今天有沒有在花時間，深化那個 10%？

---

如果你對職涯轉型或系統思維有想法，歡迎在下方留言，或寄信給我聊聊。