職涯發展的第一步是認識自己。理解你的動機、優勢和劣勢，才能做出正確的職涯選擇。

職涯方向的自我檢視#

關於職涯方向#

• 我當初為什麼成為程式設計師？（我的初心是什麼？）
• 我在目前的角色中成長嗎？有什麼證據？
• 我能看到未來五年在現有公司/行業的發展路徑嗎？
• 什麼讓我興奮？什麼讓我疲憊？
• 第 7 年、第 10 年、第 15 年的成功對我來說是什麼樣子？

關於技能發展#

• 我的技能地圖是什麼？哪裡密集（深度）、哪裡稀疏（缺失）？
• 哪三個領域的提升能帶來最大價值？
• 我的學習有多少是刻意的，有多少是被動反應式的？
• 我正在建立深度還是廣度？是否需要重新平衡？

關於晉升準備#

• 我能展示處理複雜問題的能力嗎？
• 我能展現主人翁意識嗎？（當我負責某事時會怎樣？）
• 我的工作是否跨越多個領域？
• 我的深度故事是什麼？（為什麼我是領域 X 的專家？）

程式設計師的技能地圖#

必須精通（深度）#

必須理解（廣度）#

最初的 10,000 小時將用於獲取這個基礎。有一張地圖，才能刻意建構，而不是隨機學習。

三種代碼類型#

每個生產系統都包含：

flowchart LR
    subgraph 三種代碼
        F[🔧 功能代碼<br/>業務邏輯]
        C[⚙️ 控制代碼<br/>性能・可靠性]
        O[📊 運維代碼<br/>可觀測性]
    end

    F --- C --- O

    style F fill:#e3f2fd,stroke:#1565c0
    style C fill:#fff3e0,stroke:#ef6c00
    style O fill:#f3e5f5,stroke:#7b1fa2

1. 功能代碼（Functional Code）#

業務邏輯的實現。

• 複雜性來自理解真實需求，而非編碼本身
• 最難的部分是橋接：使用者意圖 → 功能需求 → 實現

2. 控制代碼（Control Code）#

執行策略、性能、可靠性。

• 非功能性考量：負載均衡、限流、故障轉移、重試
• 現代框架已封裝大部分，但你必須理解原理
• 應與功能代碼分離，避免糾纏

3. 運維代碼（Operations Code）#

可觀測性和運行時管理。

• 日誌、指標、動態配置、監控
• 經常在問題發生後才補上——最好提前設計
• 啟用生產環境除錯和快速恢復

這三種代碼應該有清晰的邊界。優雅的系統展現乾淨的分離——它們與功能本身同樣重要。

從粗放到精益的成長#

階段一：粗放而豐富#

• 大量輸出，通過實踐學習
• 快速完成功能，快速迭代
• 感覺浪費但卻是必要的，用於建立直覺
• 這個階段是必經之路

階段二：精益而精練#

• 質量改進，深思熟慮的設計
• 在努力和收益之間做權衡
• 重構成為循環的一部分
• 從完成的工作中提取可復用的模式

你必須經過階段一才能到達階段二。沒有捷徑。

炫技 vs 克制#

炫技（Show-off Code）#

• 不必要地使用複雜技術
• 添加超出問題需要的抽象層
• 更容易引入 bug
• 例如：為偽狀態使用狀態機，而不是真正的領域狀態

克制（Restrained Code）#

• 直接、可讀、高效
• 即使看不懂細節也能看到結構
• 在真正需要時才使用技術，而非提前使用
• 等待合適的時機應用新技術

年輕工程師混淆技術深度和技術難度。真正的深度是知道何時不使用高級技術。

架構 vs 實現#

架構與實現之間的斷裂帶#

• 靜態文件 vs 動態執行
• 團隊規模造成溝通障礙
• 解決方案：關注邊界和戰略位置，而非每個細節
• 接受系統會演化——引導演化，而非完全控制

系統設計的五個視圖#

mindmap
  root((系統設計<br/>五視圖))
    組成視圖
      存在哪些服務/組件？
    交互視圖
      組件如何通信？
      依賴關係、流程
    部署視圖
      在哪裡部署？
      如何部署？
    流程視圖
      業務邏輯
      控制邏輯
    狀態視圖
      存在哪些狀態？
      如何轉換？

就像工程的「三視圖」，但用於軟體系統。通過多個視角全面理解系統。