[心得] Senior … Who? and How?
one-on-one 之後重新思考團隊內 Senior 的意義。
前言
最近團隊裡面有些變化，目前是進行式，這個背景下重新對「Senior」在團隊內扮演的角色，與在什麼角度上，會有發自內心覺得「哇，果然是 Senior」的想法。
TL;DR:
senior： Why do you do things that way?
junior： Hey, there are something wrong, let me talk you and help you do things better.
第一個 one-on-one，
第二個月剛結束，
又一次無奈給予祝福。
工作約二個月，到相對有規模的公司，主要有幾個體悟：
工作經歷超過 7–10 年的工程師，真的很強！
業務問題的時程評估、 極短期限內的臨時開發迭代任務、 經驗累積所看到問題的全面性、 效能優化、如何評估導入一項新技術、效能優化調教⋯⋯
很多技術涵蓋的方向，真的需要時間去驗證才有價值。
很多知識都是比較容易被 「Junior」 職位挑戰的，以上描述幾點之中，有些部份其實很短時間內，專注在特定領域，Junior 很容易追上 Senior 的技術能力。
所以說，「技術深度」不是成為 Senior 的關鍵，只要沈得住氣、認真專研技術，Junior 很容易在特定(限縮)的 Scope 達到和 Senior 一樣的技術深度，所以可以說這是「優秀的一流工程師素養與內涵」。
聊聊 lead
如果想當 lead（無論是管人 team lead 還是管技術 tech lead）， 會花比較多時間在把「混亂的東西」抽絲剝繭，具體來說，如果是以「技術開發」上，那大概就是反覆閱讀一行一行程式邏輯，幫助團隊成員提升 code base 的健康程度，這時候 tech lead 要專精技術能力，比較多的技能點數可能會落在 code review上，如果是其他技術只能靠自己其餘時間的個人進修。
比較常見的，lead 比較會是最後選功能（大家選剩的），沒人要做活動就只能 lead 去做，很多時候不能怕手髒，想選輕鬆的。
身為 lead ，做最多的大概就是整體流程與程式碼品質，這種事情可能是多數 Senior 可以偶爾為之，但不願意當作「工作日常」甚至是 KPI 的考核項目。
對我而言，專挑沒人願意處理的 issue 去扛，扛起整個系統架構並拆除雜亂堆疊的元件，並且控管好 code base 的健康度，這樣的 lead 大概就是理想型ㄅ
回來聊聊技術
TonyQ 大大有提到：寫 code 至少有幾個層次:
1. 知道語法
2. 能組裝得出來
3. 能夠維護歷史
4. 能夠隨目標調整程式碼方針(在既有的方案跟結構)
5. 能夠挑選最適合的算法方案跟資料結構
6. 知道目標是什麼 , 不用靠別人更正
7. 別人要重寫好幾次的, 你一次就能寫對.
或你知道怎麼用最小的試誤成本換最大的產出.
8. 知道自己對是為什麼對, 錯是為什麼錯,
在最短的單位時間內找得到問題[邏輯上]的所在.
和我之前寫的心得整理，有異曲同工之處：
- 維持 code base / code quality： 它內部的邏輯，模塊之間的交互是非常複雜。
頂尖的行動開發工程師可以在 code review 中把關(不要merge有可能有問題的 code, 才能沒有 Technical Debt)，在架構上調整， 讓 app 可以持續進步。 - 效能問題：運行效能開始低落 (啟動速度變慢/某些畫面掉FPS)
- 優化問題：產品變得肥大
- 如何 migration smooth ：有些老舊的 library 須要汰換升級
- 如何 migration smooth ：現有的架構讓想加新功能不好加
- 會有一些 crash 或是 bug 非常難以解決
- 邏輯思考能力 / 思路清晰，知道如何做 diff(code) review 找 邏輯問題/效能問題 ，不是侷限於 naming issue, coding style
- 抽絲剝繭能力高 (不是設 Breakpoint 可以解的小問題)
- 溝通能力強，知道如何做有效率的溝通
- 架構上可以提出建議，分析優缺及原因
- you know Direction : 知道現在最重要的事情是甚麼，把它做好。而不是交代一件事做一件單方向接受。
1. 比如說，可以自己思考 code base 有那些問題，是不是要當下處理。 (也要思考，為什麼需要當下處理 ? )
2. 如果是有很大 impact，懂得和 stackholder 溝通拿資源(&時間)想法辦做好 / 解決，因為有很大 impact，所以花時間處理後也可以獲得很大效益。
＊之前寫的心得：
「離開 Front-end developer 新手村」：好的特質 / 行為、什麼是 「一流的人材」？
https://medium.com/ashes-note/%E9%9B%A2%E9%96%8B-front-end-developer-%E6%96%B0%E6%89%8B%E6%9D%91-e550d8b2df4a?source=friends_link&sk=f8f6b95504e6952bbf41e40b2b364cc8
Senior 的綜合經驗（工作經歷），真的是 Junior 職位短期望成莫及的。
而這些優秀的 Senior, 往往都可以把 lead 的職位做好，不過多半是他們不想把 lead 的工作當成核心。
當然，更多的是等待更好的機會，在心目中的最佳機會到來之前，還是專心打磨技術。
不過要願意把手弄髒去摸臭、爛架構，才有機會增加經驗值。
反思
當然，現階段的我是完全沒有機會的，還處與最基本的階段。
也深刻體悟到，公司「資源」分配不一樣，能做的範疇（scope）受限於「資源」。
- 時間是最急迫的資源，有限時間內能交付的產品，品質有限。
時間足夠才有機會涵蓋「測試」。 - 人才也是重要資源，但團隊規模不一樣，如果對要離職的人破例，會造成其他人的不公平，公司規模越大越是如此。
而且，不同公司、不同階段（比如初創 early-stage 或是擁有相對成熟市場的產品）可以給出的條件有限。 - 如果公司的業務交付，集中在特定人身上，該人卻沒有承接任何職務（如 Tech lead），有可能短期規劃會有離職的打算。
- 承上，如果公司的業務交付，集中在特定人身上，其他人沒有機會了解或參與，這種「不透明」的業務場景，容易造成極大問題。
如請假、生病、離職 …etc 類似巴士問題的感覺。
不透明的業務場景，流程上、職務任務分派、開發流程難以檢視或讓團隊其他人有經驗、學習的機會。 - code base 提升到一定程度，會思考到重構、函式重複使用、模組化 … 等技巧。
相對的，如果公司有多產品，但很常發現 A repo 搬 code 到 B repo（頻繁搬遷不同 code base 且內容高度重複），應該思考到架構調整的問題。
還有很多很多問題，不過這都是成長的一部分了。
有機會再和大家交流。
