[職涯 x MentorShip]如何提升專業技能實力？要追求廣度還是深度？
我原本只想打300字小短文......
本節快速導覽
技術精度與廣度的5W1H
本科系出生，真的很重要嗎
聚沙成塔 - 那些提升的tool & tech
同是Engineer，各職能在意什麼
那些與技術並肩重要的事
技術能力之於工程師，有點像翅膀之於鳥，就算沒有翅膀或有翅膀但不會飛，也不是不可以像雞一樣在陸地上啄食生存比如換靠一張嘴寫程式(X
技術精度與廣度的5W1H
關於這個common issue其實在我成為一枚engineer後，就不斷地接收到多種觀點，在月會的前一周還剛好跟同事與mentor討論過
討論一個問題前要先來做名詞定義:何謂技術能力的廣度與深度?(但這裡沒有要開始跑pre DDD
- 廣度 — — 掌握多種技術工具，能解決多樣性的業務問題，利用廣度關聯發揮綜合效益
ex.在infra設計時，如果同時知道server-base跟serverless，可以應對業務場景採用相對合適或混合solution - 精度 — — 精通一項技術或工具，深入研究並至少達到可獨立開發的水準
如果整天要問GPT的話那肯定要擔心關於精通程度的部分
在個人經驗中，成為工程師的初期不免技術焦慮，最常跟工程師朋友開玩笑的一句話就是「生命有限，工具無限」，尤其在作為product owner的時候恨不得自己就是chatGPT(X，下知前後雲端上知infra/devops再疊加各種domain knowledge與合作溝通團隊管理等soft ability(打到這就感覺好焦慮
而再成為更資深一點的engineer後(是也沒資深到哪去 ，關注點逐漸開始從一項特定skill/language/tool轉移到了更加基礎卻不斷被強調的那些CS基礎/語言底層/程式架構等等但也可能只是真的學不動了(x
是什麼push我不再只是追隨最新最好最廣的skill呢?
也許是一次拜讀了staff engineer level的code base的經驗，也許是一次code review/pair programming想要討論最優寫法卻不明白背後的why，也許是探討技術選型時發現自己思考維度的發散與單薄(然後沒打贏覺得很不爽((重點完全偏掉
在這次分享，Mentor直接給我們了一個結論:先追求精度再追求廣度
為什麼應該先求精
核心競爭力與豐富經驗這兩項相對比較好理解:
「活下來的公司才有技術債」，尤其在大公司會面對許多legacy code，如何在龐雜的歷史因素下去維(通)護(靈)甚至汰舊換新，又或著為了解決一個冷僻問題開始各種翻source code，這些都是邁向senior之路的起點
而技術美感這點比較有意思的是 — 如何提升使用者體驗
以後端開發為例:
後端常常需要根據需求去開發對應的API，但不一定每次的開發都能夠顧全到所有的邊界問題及使用者行為，最直觀的結果就是 — — 各種500 error
關於這個例子個人還蠻有感悟的原因是:去年接過某個API，結果文件上竟然寫著200 error，同事還開玩笑說這一定是挾怨報復XDDD
關於精通的標準
- 教學相長
「教就是最好的學」
當要帶著比自己Junior的小夥伴時，常常會遇到一些需要debug的情況，自己動手直接解決是一回事，但要讓對方有效align「你做了什麼及為什麼要這樣做」，就非常考驗個人功力是否扎實到能夠自信與直接的應對所有疑問 - 解決複雜問題
當一個issue你去問GPT100次它還是在一本正經亂唬爛(?)的時候，也許這時不是你prompt的不夠精確，而是這個問題本身具備一定的複雜度
雖然大部分的技術問題就算再複雜也會有被解決的一天，重點是:你能多有效率地去澄清並定義出問題本質，化繁為簡後應用經驗認知去正確地處理它 - 跟專家交流
「一千個人眼中就有一千個哈姆雷特」
在不能保證自己具備認知全局的情形下，跟專家交流請教建議就是重新定義學習天花板高度非常好的方式，也會在交流的過程中有意外之喜
在專精後追求廣度
當積累到一定程度時，就像樹要開始萌生更多枝枒，這時就可以用「以終為始」的角度來去審視「我要長成什麼樣子的樹」
這階段的學習已經不太像是愛麗絲夢遊仙境一樣毫無準備就闖進了一個新世界，更像是已經擁有一個日漸豐富(但可能也有點重)的工具箱，在得到一個新工具時，想的也不再是「我想拿這把槌子去敲一百個釘子」而是「了解每個工具都有其存在意義與優勢場景」
「這時知識會融會貫通而不是各自平行獨立」
在回顧這個topic的時候，忍不住想到了5W1H
本科真的很重要嗎
有一個有趣的互動小橋段:
現場非廣義本科舉手的人比廣義本科的人還多，所以本科的大大們都去哪裡了呢?
:在新竹開校友會(??????
其實在成為工程師後，不是沒有為了自己的學經歷擔心過：沒有那一張紙，是不是會永遠碰不到某些門檻
而在今年求職時看著職缺大多數寫著「本科相關優先錄取」的時候，要不要規劃重回校園這件事又再度出現在我的人生議題清單中（也不可避免的有受到朋友影響，好幾位朋友剛好在今年重返校園讀博讀碩🤣
真正重要的東西從來不是那張文(收)憑(據)
在討論中似乎沒有談到一個肯定的結論，但在默默之中大家又似乎一致肯定了某個答案:
如果產學可以接軌，是業界太落後，不是學校太厲害(別槓，你槓就是你對XDDD
或許現在有很多所謂的轉職班會去教求職市場現階段最需要的技術工具，讓你在短期內可以跨進門檻成為一位工程師，但這不代表:「你能知道所有你不知道的事」
什麼是不知道的事呢?
如果你不知道什麼是Big O，你不會知道Redis文件上那些時間複雜度所代表的意義及實作上的影響
如果你不知道array在記憶體中的儲存方式，你不會知道為什麼array在不斷擴張時必須得一直搬家
什麼是負載平衡?什麼是CAP?什麼是garbage collection?什麼是source leak?
這些例子並不是為了賣弄所謂的知識焦慮，也不會在短期內讓你找不到工作(雖然現在的就業市場也是不好說
但長期來看，如果一直不重視這些，不僅會更快的遇到職涯瓶頸期，也會拖慢你的學習效率
畢竟不管一個技術或工具再新潮，萬變不離其宗
這也是為什麼當某個language剛推出的時候，你會訝異於這麼快就有一堆人馬上掌握並了解這門語言改善了哪些舊有問題
樹想長得越高，根也要扎得越深
聚沙成塔 — 那些提升的tool & tech
在這次分享中也有很精采的分組討論時間，關於工程師提升自我的方式分為了以下四個討論方向:
程式編輯器與開發者工具/硬體配件/程式語言與技術框架/學習資源與社群資源
因為個人參與的是程式語言與技術框架組，所以以在這組get到的及個人感想為主要記錄(其實也有其他組的但暫時寫不動了
一開始原本都把LangChain的PPT準備好了(我好卷)，也一面思考同時有前後端跟data engineer的組合會不會變成大家各說各的
不過真正進行的方式是讓大家分享近期在工作上遇到的挑戰(為這個討論方向點讚
在分享中會發現大家遇到的挑戰其實很類似，比如:
如何應用OOP/FP/TDD/DDD等
如何學習新技術與學習舊技術時是否會跟個人職涯發展有所衝突
更加senior一點的engineer遇到的挑戰可能會是:
作為product owner如何分工及maintain現有架構
如何降低風險導入新技術
如何帶Junior
如何在多重工作下平衡與取捨
整個討論讓我意識到的是:
雖然一直把自己視為超級junior level的工程師，也在新一份工作中有所謂的適應陣痛期，但眼下這些挫折與困難並不是因為我能力不夠或資質愚鈍，而是因為我在鞏固自身技術基礎的同時，還同時挑戰mid engineer所需要應對的各種已經不侷限於單個技術本身的複雜問題(雖然最近真的好累但還是超感謝有這個鍛鍊機會
同是Engineer，各職能在意什麼
在交流這個topic時，可以發現真的是隔行如隔山(是這樣用嗎
- 後端組
追code-過度clean code跟clean architecture
SOLID
資料庫
流量-「小流量跟加錢(?)想怎麼寫就怎麼寫」/CI - Data組
ETL
數據sense
data warehouse
數據品質
MLops
「不可能用一個 ML model打天下」 - 前端組
觀念本質的理解與轉換 — vuex跟redux:監聽與修改資料的方式完全相反
在後端組交流時得到的感悟是:
比起去擔心某個技術層面上的事情，自己還是不免會被「人」影響 — — 在做技術選型時，不僅是考慮本質要解決的問題場景，還需要顧慮到現有團隊的技術傾向，並且在「不要忘本」這件事上多次被Senior反覆提醒:諸如就算這個技術選型沒有問題，但對於現有團隊來說，需要花多少時間去跨過這個選型所帶來的gap跟花多少effort去maintain等
現在回顧思考，自己再senior一點，對技術本質掌握程度再高一點就能解決這個困惑嗎?
也許可以，又或著有更多我尚未發現的隱性因素存在並影響著
但也許這個困惑的solution其實很簡單 — — 被炸過了再去學，控制自己的預期(雖然這句乍聽之下真是有點驚悚((咦
那些與技術並肩重要的事
我稱之為心態篇XDDD
Junior 與 Senior 也許存在的那條分水嶺
記得在討論中有engineer分享到:常常會聽到Junior抱怨自己就是不斷的在重複開發專案，感覺沒有在工作中獲得成長所以選擇跳槽
「有些人開發專案就是開發一個專案，沒有帶走一些什麼可以遷移到下一次的工作場景當中」
不過我想這也許可以被延伸為「複盤後找到成長目標的能力」 — — 你到底是在一年完成10個專案，還是10個專案的本質都在重複做同一件事
若真的10個專案的本質都在重複做同一件事，那為什麼做的人會是你而不是別人?
如果換成別人來接手，你能保證你在這些專案實踐的都是「最優解」而不會讓別人有翻掉重構的機會嗎?
追求的並不只是單點的新潮與主流，而是交織成脈絡
聽到這點時想起之前聽過cisco的資深工程師分享，大意是:今天出A明天出B，難道你真的要每個都去學會嗎
若學到的知識永遠停留在表層，就像買了一堆書堆在那，你可以知道書名跟透過書封大致了解到裡面的內容，但如果沒有進一步翻開，甚至進一步去歸納總結，就很難精煉出它們背後存在的關聯也許10本書的重點其實殊途同歸(咦，在應用時也就難以擁有能夠快速調取的能力
理解不同場景的本質問題才有所謂pros跟cons產生的cp值
在分享時有人談到了鳳凰專案 — — 三步工作法，不過更讓我印象深刻的是:
每個人都有流程，但對問題掌握的細緻度會導致流程在當下場景發揮效用的差異
記得以前在consulting產業時，一開始確實會對眾多問題個別花費大量精力去處理，但在累積了一定的knowledge base後，在每一次諮詢時都更加能夠體會到當時Leader反覆強調的「90%的問題都能夠用10%的模型解決」
並不是因為這10%的模型有多厲害，而是在最一開始澄清與定義問題時，透過經驗與認知的助力更能夠洞察到真正的pain point，也避免了「花太多時間想不存在的問題」
如果真的要自救 — — 求生意圖的必要性(?
對這點也很有感是因為近期剛好接觸了擁有不同態度的Junior在對於面對問題時所展現出來的態度 — — 其實我們都知道那些技術問題有對應的解決方案，但對於超新手來說，他們是否願意克服面對未知的心理障礙，是否願意把手「弄髒」，親自下泥潭去撈找可能存在的答案，又或著以自己能力遍尋不到答案的時候，又會做出什麼樣的選擇與行動?
也許這裡涉及到的包含了一個人的知(認知)跟能(能力)，不過若是沒有最一開始的願(意願)，縱有再多的知跟能也終將無用武之地
