譯者：雲昭
什麼是“首席軟件工程師”？許多公司給出的定義都有所不同。圈內一些人將之稱作“員工工程師”（ Staff Engineers）；而在其他一些公司，他們是眾人擁戴的團隊領導者，還有一些接觸不多的朋友，將“主管”（Lead）和“首席”（Principal）混為一談。那麼，首席軟件工程師，究竟是怎樣的存在？有哪些核心的職責呢？
Roberto Gambuzzi，目前一直在擔任首席工程師的職務，同時也是Magento認證開發者（Magento，一套專業開源的PHP電子商務系統）。自1997年開始，Roberto就成為了一名程序員，在長達25年的時間裡，他曾在AWS、谷歌等幾家巨頭公司內屢次擔任首席軟件工程師的角色。
不得不說，Roberto是穩穩的第一代程序員了，在各科技行業給出的定義非常不一致的情況下，他是如何看待這一角色的呢？Roberto結合自己的實際經歷歸納出了6個用以定義該崗位的關鍵概念。
個人貢獻者（IC）：編碼圈的扛把子
很多人認為，職位一旦掛上“首席”就意味著這個角色需要參加各種大大小小的會議。但首席軟件工程師並不是這樣子的。實際上，需要他們參加的會議並不多。首席工程師也是工程師，編碼依舊是“天職”。他們依然需要與代碼打交道：進行系統設計，修復bug，優化數據庫等等。在代碼世界裡，他們要探索其他程序員害怕去的地方。
他們要處理各種疑難雜症：進行繁瑣的外部依賴版本升級，關注測試覆蓋率，解決外部庫和內部代碼的安全問題；他們審查其他開發人員的代碼，並且通常會將他們挨個惹惱一遍：在代碼的關鍵部分要求更多的日誌、更多的指標、更好的錯誤處理、更好的算法。最氣人的是，他們知道什麼時候可以不那麼嚴格，去降低這些限制。並非所有軟件功能都具有同等的重要性，Roberto在這裡舉了一個例子。在電子商務中，必須始終有效的功能包括：查看產品、添加到購物車、支付購物車。其他的諸如：建議、歷史訂單、發貨費預覽、營銷電子郵件等等，相較而言就沒那麼重要了。因此，這些模塊的程序，一般都會出錯。當然，但無論如何，這些Bug都必須儘快修復。
不盲從：為對的任務選對的技術
他們懂得很多技術，可以為真正值得展開的任務選擇正確的技術。“首席”當然需要“博學”，這一點毋庸置疑，也只有做到技術上的“博學”才會讓這個角色有“固執己見”的底氣。他們必須知道語言、數據存儲和其他粘合技術之間的差異。另外，首席工程師絕不能盲目追求炒作，必須深入瞭解背後的特性與原理，不能浮於表面。例如，Postgresql數據庫仍然是解決大多數問題的最佳方式，而將數據保存在S3上並使用AWS Athena可以解決其他問題；Java在許多場景下都能有效的解決問題，Go往往擅長的是解決其他問題，同樣，Rust很快，但構建時間很痛苦；Python可以用於請求密集型API嗎？是的，如果任務不是CPU密集型的。如果想成為首席軟件工程師，隨時更新自己是常態，不要追隨炒作。切忌把當下流行語掛嘴邊，卻不知道自己到底在說什麼。
輕輕推：更新公司的技術棧
首席軟件工程師必須不斷突破公司現有技術菜單的界限，但要輕輕推。當然，一家公司必須始終對變化持開放態度。因而首席工程師被受任之際，往往會給予更新公司技術棧的重任。
在推廣新技術時，一定要尊重之前遺留的歷史。一家公司選擇技術背後有很多原因，要推動變化，就需要公司內部的“政治資本”——
對於那些通過內部晉升而來的人來說，這種資本已經存在，因為他們已經在公司內花費了大量時間在相關方建立關係。
而對於直接僱傭的情況，你就需要一些時間來影響“現狀”，因此，首席工程師也需要良好的溝通技巧。
這裡之所以說是“溝通技巧”而不是“軟技能”，是因為在Roberto看來，“軟技能”這個詞的明面含義會讓人覺得：這些技能很弱，但事實並非如此。對於軟件開發人員來說，他們可能更擅長的是與機器交互，而不是跟人“鬥智鬥勇”。同時，首席工程師需要提出新的想法。整個過程可能會有抵制，這是關乎人性、意料之中的事情。要推廣新技術，就要學會用數字和指標來說話。如果你能證明從Java遷移到Go，會讓AWS的賬單成本降低為十分之一，那老闆當然樂於接納Go的方案。
影響力：跨團隊輻射業務
“高級（Senior）”和“首席（Principal）”有沒有明顯的分界線？答案很清楚，那就是影響範圍的大小。首席軟件工程師必須跨越多個團隊。他們從不同的角度瞭解公司的業務。達到這個水平需要時間。
首席工程師可以被分配到一個團隊，但也可以在團隊之間跳轉，每次都從事不同的項目。參與各種項目，更多的是個人/公司的決定。在大公司（如亞馬遜AWS），首席工程師的影響範圍可以是至少50名工程師，較小型的公司可能會少一些。那麼，一家小公司需要首席工程師嗎？對於一家小公司來說，首席技術官和首席工程師通常是同一個人。如果首席技術官不夠熟練，則需要首席工程師，但解決問題的範圍會更小一些。
教習官：非技術人指導也講究
大多數時候，指導開發人員都很有趣。他們想要學習，共同點是幫助人與人之間的信息傳遞。但並非所有參與軟件開發的人都是軟件工程師。產品經理、用戶體驗設計師等等也在那裡。首席工程師必須用更簡單的術語解釋，不要深入到技術實現中，解釋公司使用的技術的侷限性，可以做什麼來改進，以及技術決策會給公司帶來多大的成本。不要使用流行語或首字母縮略詞。比如，PM有時會要求無限量地保留用戶數據，以在網站上獲得更快的用戶體驗，但所有這一切都有成本。首席工程師必須能夠解釋所有這些，並幫助尋找權衡。
高產高效當先
首席工程師不是經理。他們無須進行冗長的彙報。讓其他程序員更happy的工作，也並非這一角色的職責。首席工程師的作用在於令開發人員高效、高產出地工作，而不是像經理那樣使用組織技術去改善公司內部的開發體驗。一條需要三天才能運行的管道，首席工程師將努力使其在30分鐘內運行。可能這一結果，會讓每個人都更開心。但首席工程師不會處理其他類型的問題，這些問題通常是經理的問題，如績效、晉升、個人問題…
晉升首席軟件工程師是好事嗎
升職總是好的，每個人都喜歡更高的薪酬和Title。選擇了首席工程師，就意味著：雖然你將會有更多的會議和更少的時間來編寫代碼，但是你的代碼會產生更大的影響。如果你決定挑戰這個角色，需要考慮一下問題：首先，在這個級別獲得晉升或聘用是不同的。回到“影響力”的話題，作為新員工加入這一級別的公司具有挑戰性，因為同事、經理和整個公司都希望看到這種影響力。但作為一名新加入的成員，你需要適應公司的標準和技術。其次，稱謂的變化無需太過計較。在目前的公司中被稱為“高級”（Senior）的人可以成為其他一些公司的“負責人”（Principal），反過來也是這樣。所以要注意這一點。工資可以很好地反映工作水平。如果一家公司給你提供一個首席軟件工程師的職位，其基本工資與你目前的高級職位相同……那麼這家公司可能是一家小公司。你必須只為這個角色接受這份工作嗎？答案是否定的。
在Roberto看來，工作是為了金錢或經驗，而不是為了頭銜。如果在另一家公司以同樣的薪水成為首席軟件工程師可以教會你一些東西，那就去做吧。僅僅追求“首席”的頭銜而去，那就得不償失了。最後，切記：“權力越大，責任越大”。
總結
“首席”是一個自帶光環的字眼，技術圈也不例外。從“高級”、“資深”到“主管”、“經理”、“負責人”、“CTO”等等，開發人員的職業發展終歸繞不開這些，P崗、M崗的選擇這裡不再展開，但如果你選擇在技術崗位上縱深發展，那麼首席軟件工程師，又何嘗不是一種非常契合的崗位！代碼世界的魅力需要有人帶頭推動，既不像CTO那樣更側重業務的視野去考慮全局，又不會深深陷入某個項目團隊重複造輪子，技術原地踏步，這樣對“首席工程師”的描述可能會有些失真，但對於熱衷於推動新技術的開發者而言，將變得非常有意義！