ExplainThis 全端開發雙週報 #77 資深工程師需要能有效面對模糊的工作任務
資深工程師需要能有效面對模糊的工作任務
嗨～歡迎閱讀第 77 期 ExplainThis 全端開發雙週報！
在進到這期的內容前，想與讀者們分享，最近在 ExplainThis 的 E+ 成長計畫正式突破千位讀者，非常感謝從三年前開始支持的讀者，也歡迎最近加入的新讀者。
如果你是前後端軟體工程師，想在職涯持續成長，，歡迎加入我們籌劃的 E+ 成長計畫。E+ 每週都有前後端、軟體工程、AI 工程等主題深度文，同時搭配線上課與社群。如果有職涯選擇的問題，我們在 E+ 成長計畫有專屬的夥伴信箱，會用多元的觀點聊職涯選擇，過去很多讀者回饋很有幫助。感興趣的讀者，歡迎加入 (連結)
以上，讓我們進到這期的主題文章～
資深工程師需要能有效面對模糊的工作任務
當工程師遇到各種問題時，往往都不是被清楚定義的。先前我們在 如何做好技術設計? 一文談過，做技術設計時，務必要先釐清好需求。因為如果沒有釐清好要解決的問題，很可能會導致解決了不對的問題，讓花了很多時間開發出的解決方案變得沒有價值。
為了避免這種狀況發生，很多公司在面試時，面試官可能故意不揭露特定資訊，藉此來測試候選人是否會主動去釐清並解決對的問題。
在實務上要做好這件事，鍛鍊「有效面對模糊情境」的能力 (navigating ambiguity) 是個關鍵前提。這也是邁向資深不可或缺的能力。不過相信讀者可能會問「有效面對模糊情境的能力」具體如何被體現? 該如何做到? 我們在這篇主題文會來一探究竟。
「有效面對模糊」如何被體現?
在談如何做到「有效面對模糊」之前，讓我們先來談表徵。要有效判斷一個工程師，是否具有能面對模糊的能力，可以透過觀察其行為來判斷。
舉例來說，在 AI 浪潮席捲業界後，你突然收到部門主管要求「為團隊導入 AI」 這種缺乏各類具體細節的需求。如果缺乏有效面對模糊的能力，很可能會出現以下的狀況：
在聽完主管交辦完任務後，可能開始感到有壓力、慌張，心裡想「我只是個寫應用程式的全端工程師，又不是 AI 專家，突然要我負責導入 AI，根本找錯人了吧。如果最後做出的成果不是上頭想要的，不會又要我來背鍋了吧」。
這種狀況並不罕見，因為在現實世界中，很有可能主管自己都搞不清楚導入什麼 AI、導入到什麼程度、有多少資源，甚至也沒想好如何衡量與判斷成功等等。但假如沒有「有效面對模糊的能力」，當遇到這類狀況，很可能會直接慌掉，不知從哪裡開始，又或者嘗試行動卻亂槍打鳥。
但如果具備「有效面對模糊的能力」，在遇到一個需求不明確的任務時，會主動出擊，去釐清問題，同時去找尋機會點。
舉例來說，會先跟主管約一個 1:1，詳細來聊主管對這件事情的想像，去了解為什麼想要執行這個任務，期待在一週、一個月、一季後分別看到什麼不同。
假如發現主管自己也說得不清不楚，也不會因此慌張，而是會先回過頭根據主管發起這個任務的契機 (例如因為看到業界其他公司都在導入)，來列出目標的假設。例如，提高開發生產力、降低開發成本，或者透過導入 AI 促發創新等等。然後拿著假設回過頭跟主管討論哪一項最重要、為什麼。
即使都是過去沒有導入 AI 相關的經驗與背景，上面描述的兩種類型的工程師中，可以看到第二種工程師是能更有效面對模糊的。
在這邊推薦讀者可以稍微暫停一下，試著反思一下自己過去的經驗。在過去被分派到自己不熟悉、沒經驗的任務時，你的反應會是類似第一種工程師，還是第二種呢? 如果你也是在遇到陌生且模糊不清的任務時，就開始慌張不知所措，以下讓我們來談如何做到有效面對模糊。
資深軟體工程師，特別需要養成這能力
在具體談如何有效面對模糊前，想特別提一點，由於許多 E+ 的讀者目標是成為資深工程師，在邁向資深的路上培養「有效面對模糊」這個能力是不可或缺的。因為越資深的軟體工程師，越常會要面對模糊的情境。一般初階的軟體工程師，是接受被分派的任務，例如某個已經被清楚定義好的功能，所以不太會有要面對模糊的情況。
但是資深工程師則不一樣，資深工程師要面對的可能不是那麼清晰的，很多時候要跟產品經理討論，去了解終端用戶的需求、產品面的需求，然後從技術的角度去評估有哪些可能的方案。假如某些產品端一開始沒想到的，資深工程師不能就沒考慮，然後事後抱怨。
更進一步說，資深工程師面對的模糊，可能有很多種，從不確定在新的需求下要選什麼技術、不確定選擇某個技術後要如何實作、不確定要花多少時間才能解決問題、不確定會不會有任何突發的意外。
當某個新技術出現時，資深工程師要能判斷是否採用、如何推動；但新技術意味著過去沒有相關的資料點可以參考，不確定性很高。在這種情況下，如果缺乏面對模糊的能力，將難以做出技術決策、難以帶領團隊往前。
閱讀更多
在了解「有效面對模糊」很重要後，相信讀者會想了解可以如何有方法地面對模糊。我們在 E+ 的主題文有詳細談，有興趣的讀者，歡迎加入 E+ 成長計畫。
本文為 E+ 成長計畫的深度內容，截取前三分之一開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)
## 本期推薦
上週開始，新年度的史丹佛大學的 CS 153: Frontier Systems 正式開課 (連結)。這堂課從去年開始，就集結業界全明星陣容講者，從大家熟知的黃仁勳、蘇姿丰、Sam Altman、Satya Nadella、Andrej Karpathy，到各大公司的執行長或 AI 負責人，來談 AI 業界最新且最重要的趨勢 (連結)。
近期社群中的一大新聞，是每週下載量破億、JavaScript 生態系中被廣泛依賴的套件 axios 被供應鏈攻擊。今天讀了 axios 套件維護者寫的事故檢討，真的覺得這次的攻擊手法讓人開了眼界。我們寫了一篇貼文來談事故檢討的摘要 (連結)
最近 Claude Code 的某個部署失誤，導致 source map 公開，進而讓原本閉源的程式碼變公開 (連結)。在這種重大事故發生時，團隊如何做事故檢討會很關鍵，Claude Code 負責人做了很好的示範 (連結)
這週 MDN 分享了一篇《Under the hood of MDN’s new frontend》深入談 MDN 團隊如何打造新的前端架構，非常對進階前端感興趣的讀者一讀 (連結)
《Unconventional PostgreSQL Optimizations》一文談了許多可能平常不會想到，但是對 Postgres 效能最佳化有幫助的技巧 (連結)
Cloudflare 團隊分享了《A one-line Kubernetes fix that saved 600 hours a year》一文，談如何透過一行簡單的設置，大幅降低等待時間，這種實務的問題排查與解決經驗讀起來特別有收穫 (連結)
最近社群中出現一個討論度很高的網站 30u30 fyi (連結) ，專門追蹤 Forbes 30 Under 30 入選者裡頭後來被起訴詐騙的案例。這讓我們想到 Paul Graham 在十多年前寫的《How to Do What You Love》談選公司時，別讓聲望成為決定性因素 (連結)
彩蛋
這期的文末彩蛋來自先前 Andrej Karpathy (OpenAI 共同創辦人、前 Tesla 的 AI 總監) 發文 談到要成為專家，有幾個重要的原則。
第一點是用透過具體的專案，迭代式的學習 (換句話說，第一次沒做好也沒關係，修正後持續嘗試，就會越來越好)，在過程中要深入，根據遇到的問題進一步去深究。
第二點是要去總結、去教自己學到的東西。這點是 ExplainThis 很有感觸的，因為在寫 ExplainThis 的內容時，很有效地加深我們對過去所學的。
最後一點也是我們認為最重要的一點，就是自己唯一的比較對象只有過去的自己，不要去跟別人比較。每個人都有自己的成長步調，與其花時間跟他人比較，不如專注在檢視自己是否比昨天的自己更進步了。
即使每天只有一點點，當今天的自己比昨天的自己，在技術或軟實力上有多一點點的成長，長期累積下來也會有非常顯著的不同～