曼陀號是一個為期六個月，邀請各領域專家擔任船長，分享經驗傳承來幫助水手縮短摸索時間並突破職涯瓶頸的計畫。我參加的是 Enginearing 組，在今年擔任助教的角色~
第七屆 Enginearing 組的船長是顧職創辦人 Bryan，本次月會分享的內容「技術力:如何有效學習一項技術」介紹了很多將技術學得更扎實需要的技巧，很適合已有明確學習想法的人閱讀此篇筆記。
而去年的船長-漸強實驗室的主任工程師 Jalex 主講的月會有個相似的主題：「軟體工程師的技能養成」，聚焦於從整個職涯的角度看學習新技能，我認為更適合對職涯迷茫、連應該學甚麼都不曉得的人，歡迎大家搭配使用！
這次剛好有機會跟讀書會夥伴和去年的船長分享討論對這份筆記的看法(感恩的心❤)，以下筆記會融合兩位船長的看法～
技能樹怎麼點
廣度 v.s. 深度
現在技術的廣度可能比較不是問題，大部分的技能可在 AI 的協助下到達 60分，所以深度可能才是職場生存的關鍵。
你不可能每點都比AI強，但至少吃飯的技能要贏過AI才有價值。
✦ 值得思考：如何判斷自己的技術能力足夠深入？AI 回答不出來就可以了嗎？ - AI 回答不出來有可能是問的方式不對，可以多嘗試不同的promot 。 - 也有可能 AI 對問題背景不夠了解。(例如：大部分的公司系統架構可能有限制不能餵給 AI)
Side-Project大哉問
學技術就要做 Side-Project？
先搞清楚你為什麼要做 Side-Project
- 興趣：不要管有沒有用，做的開心最重要
- 需求：訂好目標就不要管有不有趣，能達成需求就行
如果你開始問別人我要不要做，通常就是動機不夠強烈、目標不夠明確、不夠想要。
✦ Side-project的方向： 通常做不深，在有相對資源的情況下，因此學習技能應該以公司有的 project 優先。
而個人額外做的小專題，更適合拿來做為挑戰跨領域的敲門磚，在爭取沒接觸過的領域機會時加分。因為即使在有 AI 的情況下，做出基礎 Side-Project 的難度會大幅下降，但願意花時間總是會有所收獲。
選題的三大指標：熱忱x影響力x職涯價值
- 熱忱：就是你感興趣的事
- 影響力：這件事對別人有沒有用，（例如：系統 dashboard 可能技術難度不高，但對團隊有用且老闆喜歡。(注意：需評估槓桿最大的做法，例如：開發一個報表頁面前端可能要刻 2 個月，但導入工具可能可以縮短用2 週達成一樣的效果)
- 職涯價值：因為時間維度長，是最需要賭博的部分，應該仔細評估是短期炒作還是有長期效益（例如：前端框架更新迅速，但底層都離不開 JavaScript → 那xx框架可能不是好選題，但 JavaScript OK)
用專案養出技術深度
技術深度來自於實際經驗的累積，而不只是被動的吸收
輸出導向的成長
- 選擇最有挑戰性的專案：好處是不會有人跟你搶，且老闆通常會更喜歡你：D
- 根據專案設定學習目標：如果一個project的學習目標太多，可能因為難度過高容易開天窗（例如：同時需要重構跟跨組溝通，但兩個對你來說都十分挑戰。)
- 記錄過程並於團隊分享：增加貢獻值並借此累積在團隊中的話語權。
- 迭代與深化：根據前一個專案的經驗去設定下一個的目標。
✦ 值得思考：最有挑戰性 v.s. 不能太多挑戰的目標 是不是有點衝突？
把'最'去掉就是選擇專案的好方法，專案要有挑戰性且目標明確，但同時不超出你的能力過多。
要注意的是，在開始挑戰專案前最好先確認:
(1) 資源： 找前輩詢問能不能 Support，但不是讓他當救火隊，而是在不占用過多時間的情況下能給予專案前進或設計的方向建議。
(2) 策略：你對這個專案的了解，包含為甚麼選擇這個專案、問題核心、解決方向、難點、風險等，如果沒有想清楚就貿然出發容易有很深的挫折感，甚至很難完成。而策略準備做得好，也能增加前輩願意 Support 的意願 & 老闆的放心程度。
細節決定成敗
工程師的工作：發現問題→分析問題 →解決問題→成果
- Junior ：完成功能開發
- Senior ：能從細節找到核心問題，並知道從問題經驗去重新設計log /架構/解法。
例如：系統效能下降，看似網路延遲導致（發現），實際上是特定數據查詢失敗拖慢系統效率（分析），重新設計數據查找方法（解決），系統效能提升（成果)。
這邊細節也可以理解成簡化問題的能力，需要對系統的了解和經驗累積
學習新技術要做的事：由淺入深
步驟
解決什麼問題：
- 判斷現在要不要學？
- 什麼情況需要回來學？
✦值得思考: 怎麼判斷新的/舊的技術值不值得學？
共有概念、顛覆性的創舉、能夠最長久使用的就可以學。(例如：CICD的概念可以學，因為幾乎所有工具都是用同一個邏輯；Java Springboot 可以學，雖然很久了但仍被大量使用，即使要淘汰也可以學習Migration)
操作：
- 能使用技術基本的功能，優化或解決你的情境
- 了解技術的核心概念及如何運作
釐清關聯、限制
- 這個技術適合或不適合什麼情境
- 什麼情境會失效/有陷阱/有限制
- 有什麼替代方案
輸出
- 能解釋概念給別人聽
- 怎麼教一個完全沒有背景的人這個技術
拆解與延伸
- 了解技術的核心概念: 因為功能很難超出核心概念
- 了解周邊技術：有哪些相關的技能可以點，記得沿著自己職涯主軸(例如：你想當後端可以學習前端打API的方法來輔助未來自己查找bug，但不需要鑽研前端框架細節)
- 釐清邊界：避免鑽牛角尖或用自己的短版打人家長處（例如：學習AI應用和原理可以，但 Deep learning 其實是算力競賽，可以不用學習怎麼才能比拼效能)
✦ 值得思考：邊界真的適用於每個人嗎？
邊界可能更適用於
- 創業者: 因為商業是競賽，需要把時間精力花在最有效的地方
- Senior: 了解自己的長短處，知道自己需要增強或補足的範圍
而 Junior 可以不要設限，因為職涯不是跟別人的競賽，在職涯的開始階段每種學習收穫都能成為養分。
技術的驗證
技術百百種，每個都說自己超棒，越來越多東西要學，但每個都能拿來用嗎？規劃技術的驗證！
- EX: gRPC 比 REST 快。有沒有在同資料量級測試過？你的服務能顯現出這種優勢嗎？
技術觀點不等於實際情況，重點不是對錯，而是你有沒有能力驗證。
Step 1. 設計MWE
- 設計 MWE (minimal working example): 最小可以重現問題、驗證觀點的測試，除了 wiki 的解釋，說明可以看看這個 stack overflow
- 好處：快速收斂問題、方便討論
- 如: 簡單測試 numpy 和 panda 的效能
Step 2. 學會看 benchmark
- benchmark ：通常是可量化的指標，例如: 時間、金錢、流量、覆蓋率、錯誤率等
- 避免工具說明文件只說自己的好話，應該嘗試看設計細節 (如：控制的變因、硬體條件是否能夠被復現
✦ Hint:
這段可能對 Junior 來說比較困難，比較好理解的方向可能是概念驗證(Proof of Concept, POC)，目標是簡化問題。例如：有一個API很慢，可以將整個API做的事分段看(如: Input、Query 資料庫、整理資料、Output)，找到最慢(或最貴)的部分，控制其他步驟(變因)，嘗試對其進行優化。
輸入到輸出
學習是一個內化的過程，由接收 → 理解 → 輸出
- 紀錄思考的過程，而不只是結論的知識。 因為有過程就可以複製思路。
技術文章 Template
- 開頭 Why + WHAT: 你要解決甚麼問題？為甚麼要做？
- 中段：觀察問題、測試復現、原理、提解法
- 結尾：學到的部分、未解決的問題
PPT敘事法： 讓資訊有層次
- 抓住核心問題，避免全部都是重點的資訊轟炸
- 層次結構：由淺入深、由高層概念到具體例子
- 視覺化：善用圖表如流程圖、比較表，但避免全部都是程式碼截圖
說給別人聽
- 加入實際情境或比喻
- 練習時加上觀眾反問
以上就是本次月會筆記的全部內容了，今年以不同的身分參與曼陀號計畫，很期待未來的每次收穫，這次走一個極限速度發出文章，期許自己永遠都在學習的路上，希望看文章的你也有找到自己前進的目標！
