軟體工程師是否夠資深？是否夠格當主管？

最近還算是年後轉職潮或年度組織調整潮的尾聲，仍然會有一些後輩私下來問這題「我最近跟主管提升遷，但主管總是叫我再等等，說我的績效還不夠好，但我實在無法從主管的口中問到資深工程師到底需要有怎樣的條件，連要加強哪些方面都不明確，Ascii 能說說你的想法嗎？」

• 軟體工程師具備怎樣的條件後可以獲得資深工程師的職稱呢？
• 要具備怎樣的條件才叫能夠勝任軟體工程團隊主管一職呢？

雖然這已經是個被寫到爛的題目了，但我還是想寫些「不那麼抽像、容易理解與想像得到具體行為」的答案，提供給對這題目有興趣的同學們從中挑選出具體可執行的下一個步驟。

集合 Senior Engineer、Staff Engineer、Principal Engineer 等這些工程師職稱，我個人認為該擁有的額外技能是一致的，差別只在於這些額外技能的等級高或低，例如導入新技術這塊，導入新版本語言的 Threading 新語法是這個技能中的最初級，導入整個新 Library 並實作完成且無痛轉換也許是這個技能的中高級，所以一併談即可。

1. 熟練 - 想像自己剛開始接觸一個新的程式語言或技術框架時，時常需要翻書或搜尋找答案，找範例，甚至是翻出自己過去寫過的程式碼來回顧語法，各個領域的資深工程師是不應該有這種行為的，你應該對自己負責領域的語言、語法足夠熟悉，這才能讓你接獲一項新任務時，所花費的實作時間比一般工程師要來得快速，進而產生較高的績效，你不必依賴別人或是以前的自己來指導如何工作。
2. 熟悉 - 和熟練很類似，但從 Coding 擴大為 Domain Know-how 的層次。想像你的專業領域中，接獲了一項新的功能開發，其中有許多只聽過但沒實作過的技術協定或架構，大部份新手會在每個領域各撰寫一個拋棄式的 POC 專案，等到大部份沒接觸過的領域都 POC 完了，才開始著手進入開發主線，就我長久以來的觀察，這也是新手績效遠低於資深工程師的原因之一，要想解決這個狀況，得靠閱讀、練習、紀憶、熟悉，這種擴大知識圈的工作會很快速的反饋到你的績效上。
3. 營造強者願意共事的環境 - 面試工程師時，時常會有面試者問我們偏好讓 Library 維持穩定版本，還是儘可能的追新版本，面對這題，我的回答是「我希望工程師們不是用偏好來決定這題的答案」，你必須要有能力評估專案中眾多的 Library 各自夠穩定並且夠新的版本，並且追上那些版本，否則你們所打造出來的工作環境，遲早會因為使用的技術過舊，而碰到徵才時強者不願意加入的狀況，在這種想法之下，你會發現工作不只是把功能 implement 出來就好，該做的事情還有很多很多，適當的追逐 Library 版本只是其中一個例子。
4. 追求極緻 - 這又和上前面營造環境這點很類似了，相同的是從純萃的 Coding 再往外跨，你可以用你的專案去思考，例如一個 App 從 Coding 開始到 Commit 一筆修改，到發了一個 Pull Request 再到編譯，再到軟體部署甚至用戶行為收集的整個過程，除了在 Coding 這方面以熟練和熟悉增加效率之外，你還能夠如何提高生產效率呢？例如，你撰寫了多少測試來讓出版的驗證過程更有效率？你幫多少環節做了自動化來幫助 Code Review 等行政工作更有效率？你導入了什麼新工具幫助版本驗證過程更快的發現人類可能無法發現的問題？你的產品網站容易被關鍵字搜尋到嗎？你的網站在行動裝置上執行分數高嗎？你的架構擴充性足夠高嗎？你的產品能搭配上各平台適當的人機交互功能嗎？你的產品符合目前主流的操作流程甚至是 UI Design Guideline 嗎？
5. 預知災害並避免 - 軟體工程和大多數的工程一樣，總是會有非常多種方式能夠做到外表很相似的成果，但各個作法有其各自的優缺點，愈是簡單便宜的作法，也愈容易被初階的駭客找到攻擊弱點，也愈容易在用戶的資料量累績到一定程度時因為效能問題湧入大量客訴干擾後續專案開發進度。你必須具備足夠多的資訊安全、效能問題等知識，知道各專案適合的實作方式有哪些，在組織能夠負擔的成本與風險下，挑選最適合的實作方式，這比追求極緻還需要再往外跨一些，但如果你負責的專案總是能在產出成果中涵蓋不易有資安漏洞、執行架構具備高效率的等細節，客觀來看，你肯定是個資深工程師。
6. 持久力 - 天生的資深工程師很少，天生的資深工程師也不需要來看我寫的這些文章，工程師們在有意願爭取升遷時，向主管或向前輩問到應該加強的項目或應該多承擔的項目後，通常會熱血的列出一些工作目標。但是，大部份的人只能維持不到一個月的時間，例如有人可能會說「為了達成熟練，並且提高第一時間就使用正確架構的機率，我要來讀 OOO 和 XXX 這兩本書」，但往往連第一本都看不完，甚至只看了兩章就又回復以往的生活，相似的例子很多，例如開出一堆要撰寫測試的票，但只實作了一張。建了好幾篇技術文章或教學文件的主題，但幾個月過去了還停在第一篇的草稿。不是天生的資深工程師真的完全沒關係，但你要肯演，演得夠久就變真的了。

以上各種資深工程師之於我來說，都還是如何成為一個更好的 IC (Individual Contributor) 的層次，不太有什麼團隊管理的行為被納入評等，所以我個人覺得自己的要求不算高，如何在工程師職務中升等就先簡單列出上述幾點。接下來講轉職這題，如果你想要爭取的是工程團隊主管，簡單描述一些具體的事例如下。

1. 有主見並且符合普世價值 - 簡單來說，你要盡可能想過下屬可能問你的問題，想過面試時面試者可能問你的問題並擁有自己的答案。例如今天有個下屬來問你文章標題這個題目時，你能有結構的說出自己的想法嗎？而不是和文章第一段所寫的只能只能說出效率還不夠、你還不夠強等等抽像的回應。除了有自己的想法，也要做到能夠紀錄下成員的具體事項給予分類與建議，並協助理解弱點與協助改善。
2. 教育訓練與文化塑造 - 維持團隊成員對於組織、產品的夢想肯定是團隊主管的責任，維持團隊內部技術交流的活絡也是，打造每個成員都願意具名有話直說的文化也是，尋找團隊新血，根據此時此刻組織的目標做策略，有效的考評並做教育訓練也都是團隊主管的責任，這些工作你有自己的具體執行方向嗎？順帶一提，面試技術主管時，我一定會問對方「你計劃怎麼做教育訓練」。
3. 肯做決定 - 延伸上一個項目，你難免需要中斷一個正進行到一半的專案，也難免要把一個工程師們都好想玩的酷東西的優先權往後排，甚至你為了公平性，為了接下來組織的方向改變，需要請一位當初你面試進來的同事離開團隊，你能夠不再被以前一起吃飯、玩手遊的各別工程師情緒勒索，做出對組織、對整體團隊最適合的決定嗎？
4. 做好與做完的平衡 - 大部份的書籍文章都會教我們要把事情做好，而不是做完，假設你已經是一個技術能力夠強的資深人員了，那你肯定能提出把事情做到理想狀態的方案，但身為技術團隊的主要窗口，參與各項專案開發的評估過程，在理解公司能負擔的成本與策略即時性的重要程度後，是否能夠給出平衡的解決方案，幫助組織獲得利益，幫助組織解決能夠活下去、活得好的問題，而不是單純的猛開副本、把事惹大。這其實也是常見的因應組織目標改變時，過去很適合的主管可能接下來就不適合了，必須重新找另一個新主管接手的主要原因。
5. 持久力 - 持久力又要被我提了一次，因為持久且穩定的輸出能力絕對是技術主管該有的重要表現。舉一個實際例子，大概在五、六年前我開始當技術主管職時，我很快的發現團隊主管會因為外部會議與身兼團隊主要窗口的因素獲得最多的資訊及權限，手中擁有最多資訊的就是主管本人，要做到資訊足夠透徹的佈達，由我來撰寫週報提供給所有成員，會比各個工程師寫週報提交給自己來得更透明，這件事我一做就是好幾年從來沒斷過。又例如你想為團隊安排定期讀書會時，但某一陣子若成員都在忙碌時，你能不能持續堅持下去自己找題目講，而不是逐漸的讓定時讀書會消失。又或者你覺得每週有固定的時間 Code Review，你有一直持續帶下去嗎？還是只做了 1、2 次呢？除非你想到更好的作法，或需要停止的理由，否則你必須把上述一切你認為好的事情都內化成為習慣，維持穩定的成果輸出，在這之前組織是不會放心把團隊交給你的。