Henry的部落格

文章標題： 兩週結業：從「寫程式的人」進化為「用邏輯驅動世界的職涯建築師」
內容重點： 這不是系列文章的結束，而是你新系統的上線（Go-live）。
全棧思維 (Full-Stack Mindset)： 底層是技術（底氣），中間層是溝通（接口），最上層是商業與人心（邏輯）。
持續迭代： 職場沒有最終版，只有不斷更新的 Beta 版。學會根據環境的反饋（Feedback Loop）調整自己的參數。
你的賽局，你定義： 內向者不一定要變外向，而是要更聰明地運用邏輯。
行動呼籲 (CTA)： 「這 14 天我們拆解了職場的各個層級。如果你發現自己的系統仍有難解的 Bug，歡迎填寫 [職場應力診斷表單]。我將陪你進行一次深度 Code Review，找出你的職場致勝邏輯。」

文章標題： 程式碼會過時，但邏輯不會：為什麼「寫作」是你職涯最強的護城河？
內容重點： 如果不寫出來，你的專業知識就只是暫存在 RAM 裡，重啟（離職）就沒了。
模組化知識： 將解決問題的經驗寫成文章，就是將知識「固化」為可複用的 Assets。
降低溝通成本： 當有人問你重複問題，直接丟連結。這是建立你的「個人文檔庫」。
提升搜尋權重： 在方格子寫作，是在優化你個人在職場市場的 SEO。當主管或潛在雇主搜尋你的名字，他們看到的不是空殼，而是豐富的「技術規格書」。

文章標題： 你的身心不是無限容量的 Server：學會設定職場的「Circuit Breaker」
內容重點： 工程師最怕系統死機，但我們卻常讓自己 Burnout。
流量控制 (Flow Control)： 當需求超過你的處理能力時，要學會回傳 HTTP 429 (Too Many Requests)，而不是硬吞導致整個系統（身心）崩潰。
優雅降級 (Graceful Degradation)： 狀態不好時，優先保證核心任務執行，暫停非必要的背景任務（如社交應酬）。
斷路器 (Circuit Breaker)： 設定你的壓力臨界值。一旦到達，強制「離線」休息，防止損害擴散到私人生活。

文章標題： 害怕社交？內向工程師的「異步通訊」指南：讓機會主動 Callback 你
內容重點： 內向者不需要學業務那套「廣播式」社交，你需要的是建立「API Hook」。
主動式 vs. 響應式： 透過撰寫技術文檔、在 Slack 提供高質量解答，建立你的「Read-only 權威」。
弱連結的力量： 真正帶給你跳槽機會的，往往不是天天吃飯的同事，而是那些看過你代碼、聽過你分享的「異步聯絡人」。
建立 Hook： 定期更新 LinkedIn 並分享一個解決問題的小筆記。這是在發送心跳信號（Heartbeat signal），讓獵頭的掃描器能抓取到你。

文章標題： 別再用「苦勞」求加薪：如何用 Benchmark 邏輯談出你的市場身價？
內容重點： 工程師談加薪最常犯的錯是「訴諸情感」（我很累、我很久沒調薪）。但在公司的系統裡，加薪是資源重分配。
數據導向 (Metric-Driven)： 你的績效不是「做了多少事」，而是「解決了多少成本」或「增加了多少穩定性」。
定價策略： 參考市場行情（Benchmark），這不是威脅離職，而是進行「市場同步（Sync）」。
提案結構： 就像推銷一個昂貴的 Enterprise 功能。
Input: 我過去一年的貢獻（量化指標）。
Logic: 這些貢獻如何對接公司今年的目標。
Output: 調整薪資結構，以確保系統（你）能持續高效產出。

前言：為什麼工程師討厭政治？
大部工程師最討厭的詞，除了「改需求」，大概就是「辦公室政治」。
在我們熟悉的程式世界裡，$1 + 1$ 永遠等於 $2$，邏輯是確定的。但在職場裡，你可能明明做對了所有事，最後卻莫名其妙變成「背鍋位」；或者某個需求明明技術上不可行，卻因為「老闆說要」而強行推進。
這種「不確定性」讓我們感到焦慮、甚至憤怒。我們常說：「我只想好好寫 Code，為什麼要搞這些有的沒的？」
但今天我想換個角度告訴你：辦公室政治，其實只是一套邏輯不同、變量較多、且文檔缺失的「複雜系統」。
如果你能把職場中的每個人看作一個「狀態機（State Machine）」，你會發現那些看似混亂的行為，其實都有跡可循。
核心理論：職場中的「政治狀態機」
在數位電路或軟體開發中，狀態機（FSM）根據目前的「狀態」和「輸入信號」，決定下一個「狀態」和「輸出結果」。
職場中的每個人（你的主管、PM、隔壁組的技術 Lead）也都在跑自己的狀態機。之所以覺得他們「不合理」，是因為你只看到了他們的「輸出（行為）」，卻沒看清楚他們的「當前狀態」和「輸入信號（KPI/壓力源）」。
1. 識別對方的「輸入信號」：KPI 是最強大的驅動指令
在程式碼裡，輸入決定輸出。在職場，KPI 就是那個最強大的 Input。
PM 的輸入： 上線時間、轉化率、用戶增長。
技術主管的輸入： 系統穩定性、團隊產出、部門預算。
業務方的輸入： 簽單金額、客戶滿意度。
當 PM 提出一個無理的時程時，他不是針對你，而是他的「狀態機」接收到了來自老闆的強烈輸入信號。如果你只跟他爭論「技術難度（輸出受阻）」，那是無效的溝通。
2. 狀態轉換的觸發條件 (Transitions)
一個冷靜的主管，為什麼突然在會議上發火（狀態轉換）？
通常是因為系統偵測到了「例外（Exception）」：
安全感失控： 進度不在他的掌握中。
利益受損： 這個決策會讓他在大老闆面前顯得無能。
資源爭奪： 另一個組搶走了他原本預定的預算。
實戰操作：如何「預判」不合理的人為例外？
要看透政治，你不需要學會勾心鬥角，你只需要建立一個簡單的**「利益矩陣（Interest Map）」**，這就是你的職場 Debug 工具。
第一步：建立 Stakeholder 的狀態清單
列出跟你工作最相關的 3-5 個人。問自己：
他現在的「核心任務」是什麼？（他在跑什麼 Process？）
他最近最怕發生什麼事？（他的 Error Handler 關注什麼？）
第二步：分析「側效應（Side Effects）」
當你提出一個技術提案時（例如：重構舊系統），不要只看技術好處。思考這個提案會對其他人的狀態機產生什麼 Side Effect？
對 PM： 會不會導致他這週的 Feature 延期？（如果是，他必會觸發「攔截」行為）。
對主管： 這能幫他在季末報告增加亮點嗎？（如果是，他會觸發「加速」行為）。
第三步：主動提供「預期內的回調（Callback）」
如果你預見到某個決策會讓 PM 很難做，不要等他來找你吵架。在你的「指令」發出前，先給他一個 Callback：
「我知道重構會占用三天時間，可能會影響到 A 功能的測試。我已經想好了，我們可以先把 B 功能的資源調過來，確保你的上線時程不受影響。」
當你主動處理了對方的「例外情況」，你就掌握了這場政治賽局的主動權。
結語：別關掉政治，要「優化」它
辦公室政治是職場中無法移除的「背景程式（Background Process）」。它佔用內存，有時還會造成系統卡頓。
但一個成熟的工程師，不會試圖 kill 掉這個 Process（你殺不掉的），而是學會如何與它共存。透過理解他人的狀態機，你可以減少被「突發例外」閃退的機率，把精力留給真正有價值的開發工作。
記住：職場沒有絕對的瘋子，只有你還沒看懂的邏輯。

在職場這個大型系統中，如果你只把自己定位為一個高效的「解題者」，那你充其量只是一個被高度優化的「GPU」——算力很強，但永遠需要 CPU 來告訴你該算什麼。
今天這篇文章，我們要談的是職涯進階最關鍵的一步：如何從被動接收指令的「執行者（Executor）」，轉型為參與定義問題的「決策參與者（Decision Participant）」。
工程思維轉譯：從 Function 到 Main Logic
在軟體架構中，一個 Function (函數) 的特性是什麼？
它等待被呼叫。
它接收既定的參數 (Input)。
它產出可預期的結果 (Output)。
許多工程師在職場上的行為模式，就像一個寫得很好的 Function。PM 給你需求文檔（輸入參數），你負責產出程式碼（輸出結果）。你追求的是這個 Function 的執行效率和穩定性。
這本身沒有錯，但這限制了你的職涯天花板。
要跳脫執行層，你需要將思維模式切換為 Main Logic (主邏輯)。
主邏輯不只是處理輸入輸出，它負責：
判斷條件： 決定在什麼情況下，該呼叫哪個 Function。
流程控制： 定義整個業務流程的走向。
異常處理： 當預期外的情況發生時，系統該如何反應。
你的目標，是不再當那個等待被呼叫的 Function，而是成為參與編寫 Main Logic 的人。
實戰操作：介入需求上游的三個步驟
要怎麼做？你不可能明天突然衝進老闆辦公室說「我要參與決策」。這需要有策略地「向上游移動」。
最好的切入點，就是在需求還沒變成死板的規格書之前。以下是三個具體步驟：
步驟一：按下暫停鍵，別急著說「好」
當 PM 或主管興沖沖地跑來對你說：「這個功能很重要，下週三能不能上線？」
身為資深工程師的直覺，你可能馬上開始在腦中拆解 Task、估時程。但請先等一下。從今天開始，練習你的第一個反應不是給出承諾，而是提出問題。
❌ 執行者模式： 「下週三有點趕，我可能要加班，但我盡量。」 ✅ 決策者模式： 「我理解這個功能很急。在我們討論時程之前，我需要先花 15 分鐘確認一下這個需求的背景，確保我們技術方案沒走偏。」
步驟二：追問「商業價值」，而非技術細節
在需求討論會議上，別急著問「這個按鈕要放左邊還是右邊？」或是「資料庫欄位要怎麼開？」。這些是實作細節。
你要問的是關於「Why」的問題，強迫對方釐清商業邏輯：
「我們做這個功能主要想解決用戶的什麼痛點？」
「如果這個功能不做，對業務會有什麼具體損失？」
「預期的成功指標（Metric）是什麼？我們怎麼知道這個功能做成功了？」
當你開始問這些問題，你會發現兩個有趣的現象：第一，有時候連提需求的人自己都沒想清楚；第二，他們開始把你視為一個「懂產品的技術人」，而不僅僅是「寫 code 的人」。
步驟三：提供「技術選項」進行談判，而非只給一個答案
永遠不要只給出一個「能做」或「不能做」的答案。工程師最有價值的地方，在於能看見不同技術方案背後的 Trade-off（權衡）。
把這些權衡攤開來，讓業務端去做選擇。這就是一種決策參與。
對話範例：
PM：「這個搜尋功能要支援模糊比對，而且速度要很快。」
❌ 執行者回應： 「好，那我得引入 ElasticSearch，需要兩週時間架設和調校。」（PM 聽到兩週就崩潰了，開始跟你殺價）
✅ 決策參與者回應： 「要達到這個目標，我們有兩個方案：
方案 A（快速版）： 用現有的資料庫做簡單比對，三天能好，但精準度只有 70%，且如果同時超過一千人在線，速度會變慢。這適合用來做 MVP 驗證。
方案 B（完整版）： 引入專業的搜尋引擎技術，需要兩週，但能保證速度和未來的擴展性。
請問以目前的商業目標來看，我們現在更需要『快速驗證』還是『長期穩定』？」
看出來了嗎？你不再是被動接受期限，而是把球踢回去，讓他們基於你提供的專業分析來做商業決策。
結語：你的價值，在於技術與商業的接口
從執行者到決策參與者的轉變，本質上是你如何看待自己價值的轉變。
你的價值不只在於你寫的 Code 有多漂亮，更在於你能否運用你的技術洞察力，協助團隊做出更正確的產品判斷，避免浪費資源開發出沒人要用的功能。
別再滿足於當一個完美的 Function。從下一個需求開始，試著去影響 Main Logic 的編寫。

長期以來，職場文化似乎更偏愛那些口若懸河的外向者。身為一名內向工程師，我曾為自己的沈默感到焦慮。但隨著經驗累積，我發現「沈默」與「分析」正是談判桌上最稀缺的資源。
內向工程師具備的三大談判優勢：
高解析度的觀察力：當別人在爭著說話時，我們在觀察。我們能察覺對方語氣中的猶豫，或是會議室裡細微的利益流動。這就是我們的「數據採集」。
慢思考的深度：我們不輕易給出承諾。這種「慢」在談判中會形成一種壓力，讓對方因為摸不清你的底牌而感到不安，進而釋出更多資訊。
邏輯導向的說服力：外向者靠情緒感染，我們靠數據建模。在專業場域，一個紮實的邏輯框架遠比慷慨激昂的演說更能贏得長期的信任。
不要試圖把自己改造成「外向的人」，那會導致系統過熱而崩潰。你該做的是優化你的「核心演算法」。 當你學會用邏輯去驅動溝通，你的內向就不再是缺陷，而是你最精準的導航系統。

在會議中，工程師最常被推入坑的瞬間，就是被點名問：「這功能下午能做完嗎？」或「這結構明天能跑出結果嗎？」在眾目睽睽下，內向者往往因為壓力而勉強答應，隨後迎來無盡的加班與自我懷疑。
我後來學會了一種保護機制，我稱之為**「溝通的延遲存檔」**。
當你遇到無法立即評估風險的需求時，不要直接說「不行」（這太硬），也不要說「好」（這太軟）。你應該展現專業的嚴謹：「這個變動涉及多個模組的耦合反應，為了確保結果的收斂性，我現在無法口頭承諾精準時程。給我 2 小時重新跑一下邊界條件的評估，下午 4 點前我發信回覆您確定的數據。」
這招為什麼有效？
建立專業人設：你讓對方知道，你的答案是經過計算的，不是拍腦袋決定的。
奪回主動權：你把當下的「情緒壓力」轉化為「工作流程」，為自己爭取了冷靜思考的空間。
記住，專業的嚴謹，是你拒絕不合理要求時最強大的護身符。

週末我習慣透過看劇來練習「角色定位」。很多人看《半澤直樹》或《繼承之戰》看的是熱血與恩怨，但我習慣看的是裡面的「利益平衡」。
以職場劇為例，當兩個角色發生激烈爭執時，你可以試著停下來思考：如果這是一場模擬，這兩個人的「初始狀態」是什麼？ 有些角色表現得極具攻擊性，往往是因為他們的背後有一個巨大的「壓力載荷」（例如即將到期的債務或失勢的恐懼）。而主角之所以能反擊，通常不是因為他比較會吵架，而是他抓到了對方的「非線性弱點」。
為什麼工程師要學這個？ 因為我們太習慣「線性思維」——認為 A 發生，B 就應該產出。但在職場劇（與現實職場）中，充滿了變量。透過觀影練習，我可以訓練自己在開會時，快速掃描每個發言者的「隱藏參數」。
下週一開會時，試著把你的同事想像成影集裡的角色。你會發現，當你開始觀察他們的「劇本邏輯」時，你對衝突的焦慮感會大幅降低，取而代之的是一種冷靜的觀察者視角。