Coding Hot Pot

日新月異的前端技術...學不動了


title: 如何定義資深工程師?
description: 你覺得 senior 和 junior 的差別在哪裡?
date: ‘2024-05-25T05:22:37.598Z’
categories: 職涯
keywords: 資深

你覺得 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!我卻還是一知半解,有一陣子我一直被這樣的想法困擾者,陷入了「只看得見別人的優點但看不見自己的」的焦慮,列了一堆學習清單堆積如山,消化度速度比不上新增的速度 😂,最近慢慢的體悟到其實自己已經進入一個新的階段了,只是我把自己逼得太緊,最近在調適自己的心態,擁抱自己的無知,接納自己的不足,然後期望自己不論在技術面、軟實力面,每年都有所進步,未來能夠游刃有餘的承擔資深工程師的職責!

Signal在angular v17正式發佈,意謂著angular進入了一個新的世代,一直以來angular更新view都是依賴zone.js,但效能問題一直是一個痛點,zone.js必須地毯式的搜尋哪裡有變更,從component…

閱讀全文 »

近期在工作上碰到一個產品需求是前後端必須保持長時間的連線,且當前端斷線的時候,後端也必須馬上知道前端斷線並且清除當前的連線,看了許多篇技術文章,發現不少人採用了websocket ping pong的方式來實作,websocket ping pong又被稱為websocket…

閱讀全文 »

想必大家近期在開發的時候都會搭配chatGPT吧?許多瑣碎的工作都能交給它,可以說是工程師的最佳幫手,今天想要分享我都會使用chatGPT來做哪些事情?以及我認為ChatGPT還有待加強的地方有哪些

閱讀全文 »

近期在medium上面想閱讀別人的文章,偶爾會跳出彈窗要求你成為付費會員才能觀看完整文章,這讓我不禁在思考,是否別人想看我寫的文章也會遇到一樣的問題?畢竟當初我寫文章的初衷有一部分是希望可以和別人分享技術和開發經驗,因此medium這政策讓我非常的困擾

閱讀全文 »

2023因為換工作的緣故,接觸了svelte和angular,為了磨練自己,決定用這兩個我沒那麼熟悉的技術開發,今年的時間比較充裕,一個關卡有10天的開發時間,前幾年都只有一週真的爆肝,因此這次比賽的勞累度我認為會比以往低不少(事後證明我錯了😂

閱讀全文 »

這本書在我六年前剛轉職的時候有看過一遍,但那時的我因為經驗不足,其實看完沒有什麼感觸,現在累積了幾年的工作經驗再來二刷這本書,就蠻有共鳴了,開始可以體會何謂程式碼的「壞味道」,因此隨手將書中我覺得不錯的內容摘要下來,並且會結合我先前重構的經驗跟大家分享

閱讀全文 »

一直以來處理i18n對於工程師來說是一件有點繁瑣的事情,不只是要建立語系的json檔,還有後續的翻譯文字更換需求,想必大家都有過以下的情境,假設有個網頁有多國語系(i18n)的需求,第一版的翻譯已經完成了,工程師也開發完畢,但這時候pm想要調整翻譯的文字該怎麼做,以往都會是把要改…

閱讀全文 »

說到E2E(End to End)測試工具,大部分的人應該第一個想到的會是Cypress,不過其實除了Cypress,還有一個好用的工具,那就是由微軟開發的後起之秀 — playwright,近期因為工作需求需要寫E2E…

閱讀全文 »

最近被推坑開始用vim開發,剛開始幻想自己可以像那些大神一樣,只用鍵盤就能夠在畫面上行雲流水的移動,但實際上剛開始用vim開發的我,只能用慘不忍睹來形容,平常用滑鼠習慣了,現在突然要用鍵盤來取代滑鼠真的很痛苦,coding變得非常卡,甚至比沒有用vim還來得慢,說好的極速開發呢?…

閱讀全文 »
0%