如何定義資深工程師？
你覺得senior和junior的差別在哪裡？
這是去年期末績效考核的時候，主管問我的一個問題，說真的當下腦袋一片空白，我用不確定的語氣回答：「應該是開發經驗…？還有帶人的能力？」，主管給了我一個意味深長的笑容，叫我可以好好地摸索一下
即便我在去年升上了資深工程師，但是那時的我對於資深工程師的定義還沒辦法精準的描繪，於是我決定觀察和我相同職等以及職等比我高的工程師有哪些特質之後，在今年終於對資深工程師的樣貌有了基本的概念，以下整理出幾項我認為資深工程師應該具備的能力
程式碼的品質
能在期限之內交付符合產品規格、bug數少的產出物，並且能夠寫出可維護性高的程式碼
具備宏觀視角
能從系統架構面的角度出發，去評估功能開發或是異動是否可能會有潛在風險，若意識到風險的存在，能夠提出來跟團隊討論，並且能提供其他解決方案
持續精進
雖然說每一間公司用的技術、框架固定就那幾種，基本上熟悉了這套在開發上都不會遇到太大的問題，但持續關注前端新的趨勢絕對是必要的，在你做新的技術選型的時候才有足夠的資源去做評估
技術論述能力
當累積到一定的年資，多多少少都會有帶人的機會，會把過去的開發經驗或是技術分享給其他人，不限於口頭論述，寫技術文件也是一種方式，當你對該技術的掌握度為9分，而對方只有1分的情況下，該如何讓自己站在對方的角度，以一個0基礎的角度出發，來構建整個知識脈絡，是一件非常重要的事情，如果忽略了這點，寫出來的文章就會變成只有自己看得懂，舉例來說想寫一篇如何在專案導入playwright end to end test的文章，卻只有寫到如何寫test case，沒有提到設定步驟和執行指令等等的，對於讀者來說test case是寫完了，但要怎麼執行完全沒有頭緒，因此寫完文章之後，持續的收集他人的回饋也很重要
假設團隊內部有自己的技術文件（ex.介紹專案技術架構、如何ssh到指定機器、從0開始新建一個xxx的專案…)，不僅僅是能幫助新加入的成員快速上手之外，也能夠打造一個豐富的技術文件資料庫，方便大家查詢需要的資訊，我現在待的團隊是將技術文件收攏在confluence上，依照類別做分類，因此查詢起來都很方便
那麼該如何提升自己寫技術文件的能力呢？寫技術文章經營自己的部落格或是ig就是一個很好的練習方法
決策能力
假設有個情境是網站希望可以讓使用者下載使用說明的pdf檔，那麼問題來了，這個檔案應該要放在前端還是後端呢？乍看之下放在前端並沒有什麼問題，但是假設這個檔案可能會不定期的更換呢？前端更新檔案後，就必須重新打包，然後再重新部署，那如果檔案放在後端呢，這樣更新檔案時只需要更新server上的pdf即可，少了很多工，因此檔案放在後端會是比較好的做法，當今天有個需求是前後端都能實現的時候，就必須去分析利弊，評估哪一種做法的可維護性最高
再以技術選型為例，在社群裡面聽說某某框架或某某套件很好用，要不要試著導入到工作的專案呢 ? 以技術選型來說，以往我都是看到最新最潮的工具就想要導入，但忽略考量以下幾個因素，
- 套件的版本更新是否夠頻繁？
- 使用者多嗎？討論熱度是否夠高？
- 團隊的學習成本會很高嗎？
- 能夠滿足現在團隊的需求嗎?
當然我們會有個迷思，最多人的使用的工具肯定是很不錯的吧？但未必能夠滿足團隊的需求，還是必須要從各方面去評估，當然肯定會有決策失敗的時候，像是三四年前我採用了某個ui library，但是忽略了元件可能會有客製化的需求，使用到後面發現非常的難修改樣式，只好捨棄該套件，改用tailwind css重刻ui元件，雖然說做錯決定令人氣餒，但對我來說也是經驗的累積
題外話
建議可以定期檢視一下目前有在使用的套件，當你發現使用的套件已經很久沒有維護更新了，就要考慮尋找替代方案了，不然就會發生有bug，但卻等不到修復的那天
溝通能力
溝通能力可以說和技術能力同等重要，溝通能力是為了釐清需求，技術能力是為了實作需求，假設一開始的需求就搞錯了，那麼就算後期東西寫得再好也沒有任何意義
目前我待的 F2E Team是function team的性質，會和各個產品團隊合作
因此會遇到各式各樣的pm，溝通的佔比高了不少，有的規格文件寫得很清楚，有的就…不好說，在不清楚規格的時候，貿然開發絕對不是明智之舉，需要反覆的確認，當意識到某些功能可能會跟既有的程式邏輯打架，或是發現某些規格沒有被定義到，務必要拿出來討論，但因為現在是混合辦公模式，遠端的時候無法面對面討論，在溝通上需要花費更大的心力，口語很難描述的我就會利用miro等工具畫流程圖，務必先跟pm對齊開發需求，再開始動工，
在和非技術背景的單位合作，如何轉換技術用語，讓對方也能理解也是一門課題
談判技巧
曾經遇過軟體開發已經結束進入測試階段的時候，pm突然說希望可以加入一個新功能，但經過評估過後，這個功能改動非常的大，如果是以前的我，pm的要求我幾乎都會照單全收，時程不夠的話，就加班自己吞掉，但這麼做對身心都很不健康😂，現在的我會評估的改動的風險和開發時間，和pm說明這次的改動可能會影響哪些既有的架構，可能導致QA會需要重新測試，和對方說明風險，如果pm非常堅持的話，就只能拿出planB繼續溝通…
談判技巧在職等越高的職位會越來越重要，假設你已經是一位前端小主管，底下帶了三位工程師，對於合作團隊的要求來者不拒（濫好人模式），「多加兩個需求、但時程不變」、「後端這邊評估工時不夠，所以希望前端幫忙轉換所有api 參數的單位」，諸如此類的需求如果你都照單全收，你底下的人痛苦指數絕對會破表，不合理的需求肯定是要拒絕的，用不卑不亢的態度讓對方理解我方的立場是相當重要，或者是跟對方談條件，「多加兩個需求A專案的時程不變沒關係，我會把做B專案的人員調度過來支援，因此B專案的開發時程會拉長約莫兩週，這樣你覺得如何？」
說到談判真的有很多眉眉角角，談判的態度絕對不能太強硬，會讓對方覺得反感，很和善也不行，對方認為你氣場不夠，會認為你是可以妥協的，最適合還是不卑不亢，清楚地表明自己的立場，當然進階的談判技巧還會牽涉到心理學、定錨效應、月暈效應…，又是另外一個領域了
估時能力
過去如果有一個新的專案要開發時，都是由主管估時，然後我再負責實作，估得多就賺到，估太少就使用加班大法，現在的做法和以前不一樣了，和產品團隊討論完規格後，就是要請我估時然後拉出甘特圖，假設是一個小需求的話，其實還好，但如果是數十個頁面，然後給你一天評估出每個頁面需要幾天的話真的蠻有難度的XD，在開發期間可能還會有一些零碎的雜事ex.寫技術文件、開會、寫測試，這些都會吃掉你的開發時間，因此如何精準地估時，這個我還在努力學習中
RD期望的開發時間越長越好，PM期望的開發時間越短越好
對自己的期許
雖然有時候還是會對自己拋出一個問題，「撇除年資，我真的可以被稱作資深工程師了嗎？」，一樣都是掛資深工程師，可是A同事還會ooo技能，我卻不會，B同事知道好多domain knowhow！我卻還是一知半解，有一陣子我一直被這樣的想法困擾者，陷入了「只看得見別人的優點但看不見自己的」的焦慮，列了一堆學習清單堆積如山，消化度速度比不上新增的速度😂，最近慢慢的體悟到其實自己已經進入一個新的階段了，只是我把自己逼得太緊，最近在調適自己的心態，擁抱自己的無知，接納自己的不足，然後期望自己不論在技術面、軟實力面，每年都有所進步，未來能夠游刃有餘的承擔資深工程師的職責！
