ExplainThis 全端開發雙週報 #60 軟體工程師不可或缺的槓桿思維
軟體工程師不可或缺的槓桿思維
嗨～歡迎閱讀第 60 期 ExplainThis 全端開發雙週報！
在這週 ExplainThis 的 E+ 成長計畫上架了《軟體工程師邁向資深必修的 10 個軟實力》線上課程，在課程中談了 10 個軟體工程師應該具備的軟實力。
對工程師來說，技術能力很重要，然而要能夠在職涯中有所突破，僅有技術能力往往不足夠。很常看到有些技術能力很強的工程師，因為缺少必要的軟實力，導致職涯升遷卡關，非常可惜。
這期雙週報的主題文《軟體工程師邁向資深必修的 10 個軟實力》就是節錄自課程中的其中一個重要思維。對於完整課程感興趣的讀者，歡迎加入有 700+ 工程師訂閱的 E+ 觀看 (連結)。
軟體工程師不可或缺的槓桿思維
在實際談善用槓桿之前，先讓我們透過一個情境來討論一個在職場當中非常重要的問題。
假設今天你在職場當中想要能夠有更多的產出，想要能夠有更快的升遷 給定說我們每一個人的產出都會是基於我們的投入，要如何能夠有更多的產出跟更快的升遷呢？
相信大家讀到這邊可能第一個時間會有的想法是「那就多投入一點」。的確，假設今天我們給的這個公式是你的產出是基於你的投入，那很合理的當你今天看到這個公式，想要去增加產出，那就是多去投入一點。
但是當這麼做，相信大家也會意識到在現實的狀況當中，會有一個很顯然的瓶頸，那就是每個人每一天都只有 24 小時。
而且在這 24 小時當中，大家需要睡覺、需要吃飯、需要處理一些生活上的大小事。所以假設說你今天投入越多的時間，例如說在工作上增加你加班的時間，這個東西終究是會有一個上限的。
透過槓桿突破瓶頸
假如能夠投入的有上線，這時候下一個問題就來了，要如何能夠不變動投入，又能做到產出增加呢?
槓桿 (leverage) 就是能夠協助我們突破的關鍵。
對工程師來說，有一些常見的槓桿，第一個是我們最熟悉的軟體工具。舉例來說，開發者工具 DevTools 是對軟體工程師來講，非常好用的工具，也是能讓大家槓桿的一個工具。
以大家平常在解 bug 來講，假設今天在沒有藉助任何的開發者工具的狀況下，要去解一個可能相對難去解的 bug，通常就會需要花非常多的時間去做很多的假設，然後猜測最後才可能去解決這個 bug。
但是假設能夠搭配像開發者工具之類的軟體，就能夠用比較簡單的方式快速的去定位問題在哪裡，這樣就能讓大家在給定同樣的時間的狀況下，能夠更有效地去解決更多的 bug。
除了傳統的軟體工具之外，現在生成式 AI 工具蓬勃發展之下，AI 工具也能協助於軟體工程師，在工作當中去改善我們的效率，是讓我們做事能有更高效率的高槓桿工具。
在 E+ 我們有錄製了一門 給工程師的 Cursor 工作流 — 透過 AI 代理全方位提升開發生產力 線上課程，在這個線上課程當中，我們就有談如何使用像 Cursor 這類型的 AI 工具，讓自己在平常的技術設計、開發、寫測試等等的這個過程當中，全面性提升自己的生產力。
資深工程師會為自己創造槓桿
除了去槓桿現有工具，多數資深工程師之所以能夠高效率產出，是因為懂得主動創造槓桿。
舉例來講，在寫程式的時候，假設你看到某一個東西它是有機會能夠被重複使用的，就把它抽成某一個方法或者是函式。當這樣做之後，下一次再次假設要解決相同類型的問題的時候，就可以不用重複的造輪子，就可以直接的使用自己先前已經寫過的這個函式跟方法。
除此之外，大家平常在工作的時候，假設是在一個軟體團隊的協作，主動的去寫文件也會是一個非常高槓桿的事情。
特別是假設今天你逐漸的邁向了資深的工程師，需要去帶底下的中階跟初階工程師，寫文件這件事情，能省下重複講解的時間；未來有人問類似的問題，就可以直接讓對方看相關文件。讓未來需要處理相似的問題的時候，時間全都可以省下來。
把槓桿思維放在腦中
相信多數人在讀這篇主題文之前，就聽過槓桿這個概念。然而真正要讓這個概念有效，務必要在腦中持續地去問自己「我可以利用哪些槓桿？在不改變投入的狀況下，我能如何用更快、更高品質的方式去完成眼前的任務? 」
當你能夠去問這個問題之後，接下來你在做事就會不斷地去思考、不斷地去嘗試不同的工具、知識，或者自己去創造槓桿，來讓自己在相同單位的投入下能夠獲得更高的產出。
關於善用槓桿更細節的內容，以及其他對軟體工程師重要的軟實力，我們都在 E+ 的《軟體工程師邁向資深必修的 10 個軟實力》線上課程有詳談，感興趣的讀者，歡迎加入 E+ 觀看～
本期推薦
最近 Linus Torvalds 拒絕了一個 Linux kernel 的合併請求中寫的原因，引起關於程式撰寫原則的廣大討論，其中 Time Sweeney 分享的不過度抽象化原則，特別精闢推薦一讀 (連結)
Shopify 的營運長最近發文表示，在 Shopify 的 PM 職位面試中，也開始考現場實作產品 (連結)。在有了 AI 輔助後越來越多公司在產品經理的面試中問相關實作問題。假如對使用 AI 輔助實作不熟，我們有寫一系列的文章，推薦回饋 (連結)
Designtips.today 上週分享去年面試 GitHub、Figma、Apple 等公司設計工程師的經驗，整理得非常精彩，讀了後收穫很多 (連結)
前陣子 VS Code 的終端機加入 IntelliSense 功能後，被許多人嫌效能太差，於是 VS Code 的工程師 Daniel Imms 就做一系列效能優化改善，因為 VS Code 是開源的，每個優化的 PR 都能公開看到，很精彩 (連結)
上週 OpenAI 釋出了開源版本的 GPT 模型，我們寫了關於如何用 Ollama 搭配 Raycast，在自己的本機跑開源 AI 模型，同時用快捷鍵輕鬆呼叫 AI 做翻譯、處理大小事 (連結)
ECMAScript 是現代 JavaScript 的標準化版本，而 TC39 這個由業界各大公司為代表組成的委員會，會決定什麼新功能要被加入最新版的 ECMAScript。然而 TC39 究竟是如何運作的? Daniel Ehrenberg 在《How JavaScript Really Evolves》這個訪談帶大家一探究竟 (連結)
最近看到一篇舊文《The Strange Case of the Danish Aarhus Mafia》在討論，為什麼這麼多程式語言的發明者來自丹麥 (包含 C++、TypeScript、PHP、RoR 等等)，才意識到這個人口不到六百萬的國家，竟然對軟體業界有如此重大的影響力 (連結)
文末彩蛋
先前社群中很熱門的筆記軟體 Obsidian 執行長 Steph Ango，被人問說為什麼不擴張團隊，讓開發速度變更快? 那時 Steph 回對方「我們很滿意現在的步調」。
we're happy with the current rate of progress
— Steph Ango
這個回覆雖然短短一句話，卻帶給我們很大的反思。
現代軟體業界的生態，普遍瀰漫著求快、求擴張的氛圍。就以大家很愛談的矽谷，多數公司走募資 + 快速拓展的路線；佐以競爭與比較，為了不輸給其他公司，只能不斷加速再加速。
然而，無止盡地追求更快，就是最好的嗎? 多年前一位 Google 員工寫下《This Is Silicon Valley》談到這種文化下，導致許多人受高壓而致的心理健康問題所擾。
也許我們都該練習對自己說「我很滿意現在的步調」；練習不因為身邊的人走比較快，就急著想要跟著加速。踏實地、扎實地走，即使慢一點也沒關係。