第一課：個人影響力與技術精進

核心目標：從個人執行者轉變為技術影響者。

資深工程師的技術能力不再僅限於單一功能開發，而是對整個系統擁有足夠的洞察力與 Ownership

• 擁抱技術負資產與選型決策： 我們必須能夠識別並主導處理複雜的技術債，能清晰地從「技術、業務、團隊」三個維度論證技術選型和優化的必要性。
  • 第 1 天：不只是寫好程式碼，更是要成為團隊的「核心引擎」
  • 第 2 天：技術債不是債，而是策略：從 0 到 100 的思維轉變
  • 第 5 天： 技術選型：從技術、業務、團隊三個維度，做出最優的技術決策
• 成為知識的傳播者與質量保證者： 透過 Code Review 將「糾錯」轉化為「賦能」的過程。資深工程師的每一次貢獻（包括持續記錄、持續優化、持續整合），都應旨在提高團隊的整體工程水平和架構一致性。
  • 第 3 天： 參與 Code Review：從「糾錯」到「賦能」，如何透過 Code Review 提升團隊水平
  • 第14天：打造知識分享的文化
  • 第 20 天：持續記錄，持續優化，持續整合：成為資深工程師的「選擇」之道
• 從修 Bug 到修系統： 不只是修復眼前的 Bug，而是能夠追溯到其根源，並對系統架構提出防禦性改進。
  • 第 4 天： 修復 Bug 也是建立工程師影響力的起點
• 行動指南： 將持續學習與適應視為常態。資深工程師應每季度專門撥出時間，研究目前系統中最薄弱或最不熟悉的環節
  • 第19天：持續學習與適應：保持技術影響力的長期動力

第二課：專案領導與團隊賦能

核心目標：從個人貢獻轉變為帶領團隊。

資深工程師的影響力，必須能透過槓桿效應（Leverage）放大。這關乎領導力、溝通和對齊。

• 無頭銜領導力與信用基礎： 領導力不一定需要經理職位。資深工程師要主動為專案和系統設立標準、定義方向，並推動跨團隊的技術對齊。你的影響力來自於建立團隊的專業信用和遠見。
  • 第 7 天： 所有軟實力，都是為了建立團隊的「信用」
  • 第 8 天：聊聊工程師的領導力：不一定要當主管，也能帶領專案
  • 第 11 天：專注於下一級別的影響力
• 掌握溝通藝術與駕馭悖論： 運用「非暴力溝通」處理團隊衝突，並警惕「永遠正確」的悖論。真正的影響力，是讓別人願意聽從你的建議，而非強迫接受。
  • 第 6 天： 非暴力溝通：如何用「觀察、感受、需要、請求」來處理團隊衝突
  • 第 12 天：駕馭影響力的悖論：避免「永遠正確」
• 戰略性向上管理： 將自己視為領導層的「戰略合作夥伴」，而不是僅僅的執行者。資深工程師應主動溝通對技術走向和產品風險的判斷，確保技術決策與公司戰略一致。
  • 第 18 天：向上管理，從執行者到戰略合作夥伴

第三課：產品思維與業務導向

核心目標：從解決技術問題轉變為解決商業問題。

軟體工程的終極目標是為使用者和業務創造價值。資深工程師必須將產品和商業思維融入到日常決策中。

• 深入理解使用者與開發節奏： 工程師的價值是為產品創造價值。不要只依賴 PRD，要主動理解使用者痛點，並根據產品目標選擇最合適的軟體生命週期（如非敏捷銀彈），以設計出最健壯、最具彈性的架構。
  • 第 9 天：聊聊軟體生命週期（SDLC）：軟體開發不是只有敏捷
  • 第 10 天：敏捷開發不是一個「銀彈」
  • 第 15 天： 工程師的價值不只是寫程式，而是為產品創造價值
  • 第 16 天： 深入了解「為什麼」，而不只是產品經理的 PRD
• 抬頭看風向： 資深工程師必須能夠預測未來的技術趨勢，並主動將這些趨勢轉化為團隊的技術儲備和產品創新機會。
  • 第 17 天：別只埋頭寫程式碼，抬起頭看風向
• 將 1 on 1 轉化為成長引擎： 利用與經理、導師的對話，定期校準自己的技術決策是否真正服務於業務目標，並獲得戰略性的指導。
  • 第 21 天：工程師如何透過 1 on 1 會議累積成長動能

第四課：職涯發展與遠景

核心目標：從當前工作轉變為長遠規劃。

• 資深工程師的職涯是一場馬拉松，無論技術如何精進、影響力如何擴大，我們不能忘記影響力的基礎，是先照顧好自己：
  • 第 13 天：影響力的基礎：先照顧好自己
  • 第 28 天：Work-Life Balance 的真實面貌與策略
• 學會識別和應對「冒牌者症候群」與「達克效應」，這是「心態致勝」的起點。
  • 第 26 天：工程師的「心態致勝」
  • 第 27 天：「冒牌者症候群」與「達克效應」是成長的訊號
• 從頂級工程師的經驗中學習，並利用這個框架來判斷何時是職涯的「分水嶺」。
  • 第 22 天：Google L3 到 Staff Engineer 的極速晉升術：一位工程師的「可量化影響力」哲學
  • 第 23 天：Stripe 前 CTO 深度訪談：從 Google VP 到 AI 創業者的職涯智慧
  • 第 24 天：Amazon 與 Meta Senior Manager 訪談：在巨頭中成長、領導與反思
  • 第 25 天：工程師的職涯分水嶺：我們該跳槽，還是留任？

後記

這一年對我的職涯來說是很大的轉折。

去年的我認為，只要能以極高的效率完成任務，不論是否擁有「資深工程師」的職稱都無所謂。但今年才意識到，這樣的想法可能會讓自己繞了許多彎路。

之所以會有這樣的心態，部分原因來自待在舒適圈、缺乏明確目標等問題。這點在第四課中，幾位前輩也都曾提到──在職涯初期，應該盡可能設定明確目標並不斷嘗試突破，才能持續成長。

加入現在這間公司後，我明顯感受到角色定位的不同。與去年相比，公司規模從百人擴大到近千人，而在不同規模的組織中，思考的層面與面臨的挑戰自然也不同。前三個月我發現，最難的並不是技術本身，而是如何有效地說服他人，並成功推動一個項目。

參加鐵人賽的原因，是希望藉此重新建立成為資深工程師所需的知識體系。這五年來，我沒有 role model，也沒有 mentor，一路都靠自己摸索。鐵人賽讓我花了許多時間閱讀各領域頂尖工程師的經驗，並從中補足過去的不足。

希望這次的鐵人筆記，能讓我離「senior」更近一點。

也希望成為我職涯新階段的起點。