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 總監) 發文 談到要成為專家，有幾個重要的原則。

Andrej Karpathy@karpathy

How to become expert at thing: 1 iteratively take on concrete projects and accomplish them depth wise, learning “on demand” (ie don’t learn bottom up breadth wise) 2 teach/summarize everything you learn in your own words 3 only compare yourself to younger you, never to others

7:15 PM · Nov 7, 2020

171 Replies · 2.63K Reposts · 13.9K Likes

第一點是用透過具體的專案，迭代式的學習 (換句話說，第一次沒做好也沒關係，修正後持續嘗試，就會越來越好)，在過程中要深入，根據遇到的問題進一步去深究。

第二點是要去總結、去教自己學到的東西。這點是 ExplainThis 很有感觸的，因為在寫 ExplainThis 的內容時，很有效地加深我們對過去所學的。

最後一點也是我們認為最重要的一點，就是自己唯一的比較對象只有過去的自己，不要去跟別人比較。每個人都有自己的成長步調，與其花時間跟他人比較，不如專注在檢視自己是否比昨天的自己更進步了。

即使每天只有一點點，當今天的自己比昨天的自己，在技術或軟實力上有多一點點的成長，長期累積下來也會有非常顯著的不同～