摘要：程序員是喫青春飯的嗎？等我們老了，技術過時了，公司有什麼理由不裁掉我們，去僱一些既有活力、薪資要求又低的年輕人呢？這個老生常談的問題困擾着諸多漸入中年的程序員。本文告訴你如何增強自己的核心競爭力，在知識飛速更新的行業中站穩腳跟，跨過“初級工程師”和“高級工程師”之間的鴻溝。
我曾在CS職業論壇**/r/cscareerquestions上回答了一個問題，該回答描述了我在程序員職業道路早期必須**要涉足的幾個領域，並就此引申出我爲什麼認爲高級程序員不必擔心自己的技術會過時。
我認爲社區中有很多我們不太重視的軟技能，這些軟技能都有可能成倍地增加我們工作的影響力（作爲個人貢獻者和技術負責人）。這些軟技能包括：代碼審查禮節、如何優雅地遏制範圍蔓延、如何向其他部門直觀的方式解釋高科技問題、在生產任務爆滿和日以繼夜的比賽中保持鎮定自若等。
我的這一回答獲得了很高的熱度，論壇中也有一些讀者請求我將其中的內容整理成可永久保存的版本以便於打印出來閱讀，因此我決定將該回答總結成文章發到Medium上。
/r/cscareerquestions論壇上的原問題：
我喜歡編程，甚至在業餘時間都喜歡學習，但是我仍然覺得自己要學的東西太多了，就像在跑步機上一樣，永遠在被迫追趕，永遠學不完。我腦海裏有個嘮嘮叨叨的聲音告訴我，在這樣一個瞬息萬變的行業中待著是很糟糕的。因爲等我年紀大了，自己使用的工具就舊了、過時了，年輕時候學到的經驗就沒價值了。而且我還有其他業務上的事要忙活，學習新技術就更困難了。
回到一個老生常談的問題上：公司有什麼理由爲我在舊技術方面的經驗付錢？他們完全可以聘請更有活力的孩子。年輕人熟悉最新的技術，薪水卻只用付我的1/3（並且他們願意工作到很晚）。
我覺得我可能應該嘗試轉型當個業務需求分析師、產品經理或者某種商業領域的人，因爲這些類型的角色通常不會像程序員那麼喫青春飯。雖然我並不想這樣，因爲我喜歡寫代碼，但我覺得自己好像別無選擇。畢竟我也只是一個普通的程序員，不是什麼天才大牛。
作爲一名程序員 ，編碼硬實力固然很重要。而題主如果想不明白公司爲何在花點小錢就能打發剛入行的新人的情況下，仍然樂於向我們這些“老年人”支付大筆工資，可以拿下面的問題問問自己：
- 你的代碼的可維護性如何？是否有其他工程師不停地輕敲你的肩膀，讓你解釋你代碼的每一行都是如何工作的？你的變量名具有描述性嗎？你的方法是直觀、易理解的嗎？當你發現自己在複製粘貼很多行代碼時，你是否能將這些代碼的功能寫入可重用的服務中？
- 別人能夠從你在拉取請求中留下的評論中受益嗎？你的反饋意見是有建設性，還是太過粗糙？當你發現別人的知識存在缺口時，你只是告訴他們“把這條線從ABC更改爲XYZ”，還是有能力引導他們認識到自己的方法可能不是最佳方法，讓他們成長爲更優秀的開發者？畢竟，同樣是學習新東西，授人以魚不如授之以漁。
- 如果今天有100,000個用戶創建帳戶，你的代碼是否會開始引發大量超時和500個錯誤？你能保證公關能把這事兒兜住嗎？你知道如何基準化你的更改並進行證明嗎？
- 你如何將非常技術的問題分解爲公司其他部門可以理解的簡單語言？向市場解釋爲什麼一個功能實際上不可行時，你是否會讓大量的工程術語從嘴裏溜出來？
- 你對面向對象的編程有深刻的瞭解嗎？你提出的系統架構是不是“頂多算說得通”？
- 你的寫作能力如何？在回覆電子郵件時，你是能把自己的意思表達清楚，還是發完郵件後同事仍然需要走到你的辦公桌旁，來詢問你更多的背景信息？
- 你是否會主動提出想法，使你的團隊效率更高？當需要改動現有進程時，你是否能夠向所有參與方說明收益？你能使所有人都對這一變化感到興奮嗎？你是否可以持續跟進，並確保新流程確實有效？
- 你尊重別人的時間嗎？當你要求別人幫助你解決問題時，你能否準確描述你遇到問題的代碼庫的確切定位（如拋出異常的行號、你在問別人之前已經嘗試過的debug方法，免得別人再浪費時間重複你已經做過的工作）？別人是否必須反覆問你，才能從你嘴裏撬出這些信息？在別人走到你辦公桌前，你已經整理好要問的問題並在MacBook上打開了嗎？
- 在與其他部門一起確定大型項目的範圍時，你對要開發的新功能的問題了解得有多深入？在開始編碼之前，你是否能夠考慮到每個邊緣情況？你是否能夠及早識別範圍蔓延並儘早制止，從而使團隊免於週六加班？
- 你的多任務處理能力如何？你的大腦會超負荷嗎？同樣，在處理大型功能時，比如涉及50個文件的功能……你可以一次將它們全部保存在腦海中嗎？你有養成紮實的記筆記習慣嗎？你打算如何計劃跟蹤今天下班前彈出的500萬件事？
- 當你編寫的一段代碼導致帳單頁面出錯，搞得團隊首席工程師不得不取消他們的晚餐計劃、熬夜幫你解決問題時，你會如何應對？你會情緒激動嗎？你還能理性思考嗎？你是否能夠擺脫這種情緒，並提醒自己，地球上的每個開發人員每兩天就會發布錯誤代碼？
- 你瞭解業務運作方式嗎？你瞭解爲什麼即使失業人數達到兩位數，軟件工程師也可以要求如此瘋狂的薪水嗎？爲什麼編程是如此寶貴的技能？爲什麼客戶願意爲某些超級基本的Web表單向你的公司每年支付50,000美元？你是否覺得他們被騙了？
- 領導可以放心地讓你去負責面試候選人嗎？你是否擅長通過有限的信息來對人員進行分類，並可視化他們和團隊的適合程度？你能識別出在什麼情況下，在工程方面優秀的候選人卻不能很好地融入公司文化嗎？這種候選人你會建議錄取嗎？同樣，即使你和候選人在Zoom裏聊了5分鐘就知道他不可能被錄取，你是否還可以確保他仍然可以從你們的聊天中學到東西？畢竟，語言在網絡上的傳播速度是很快的。
- 假如今天是12月28日，你被困在辦公室。你今年有點瘋狂，在9月中旬就把今年所有的帶薪休假糟蹋完了。此時此刻，同事們都休假出去high了。你還能按時上班嗎？領導不在身邊懲罰你，你是否打算半途而廢？這種情形下，是否需要領導強迫你你才能盡全力工作？
- 機會成本是一件必須考慮的事。你在平衡技術債務和推動業務發展方面做得如何？你是否會重構發現的每個微小的編碼樣式問題？畢竟大家都很難承認“這段代碼很煩人，但它確實有效，需要花費四個小時的清理時間，這段時間可以花在構建其他功能上，而這是很多客戶都在請求的”。
- 你知道如何向你的下屬反饋他們的績效嗎？你和他們有良好的工作關係嗎？你是否將他們視爲敵人？你是否正在積極嘗試減輕他們的壓力，使他們的生活更輕鬆？你是否曾經說過“你們那邊有什麼煩人的任務我可以幫忙削減嗎”？公司僱人都是有原因的，你的下屬可能比你想象的更有經驗和資格。
- 你有能力撲滅生產大火嗎？你是否會在遇到大麻煩時驚慌、不知所措（比如AWS中斷使網站癱瘓、不小心搞丟了customer_invoices表單、某些錯誤導致了不同用戶帳戶之間的數據泄漏等）？你是會在壓力之下崩潰，還是會在解決問題的同時保持鎮靜，並與其他部門進行有效的溝通？
雖然我說的話不能代表所有的初級工程師，但我確實知道自己八年前開始在該領域工作時，在情緒方面的處理是非常糟糕的。
那時的我極度自信，與人溝通很糟糕，不能毫不猶豫地處理建設性批評，爲無關的小事與我的老闆激烈爭論，浪費無數寶貴時間來解決根本不重要的問題，總是覺得自己應該得到大幅度的加薪（卻不付出額外的努力來賺錢）併爲之苦惱和抱怨，天天花45分鐘打乒乓球、玩遊戲（在慢悠悠吃了一個小時午餐後）……
我爲我的老闆帶來價值了嗎？
是有的。
你能把當時的我放心地關30分鐘，讓我在此期間獨立工作、不出幺蛾子、不拿頭撞牆嗎？
絕對不可能。
而高級開發者，就會在工作中解決問題，而非製造問題。
他們減少壓力。他們按時完成任務。他們知道如何編寫經得起時間考驗、可維護的代碼。他們值得更高的工資。他們對項目的方向可以有準確的把控。他們可以發現當前流程中的缺陷，並使每個人都接受他們的想法以進行改進。他們可以指導應屆畢業生。他們處事冷靜，不會在週二與你的最大客戶的電話會議上情緒崩潰、破口大罵。
很多人想踏實當個技術人員，並不想一直向上升去當領導當主管，我認爲這種想法沒什麼問題。編程是目前最令人鼓舞的職業之一，許多企業願意給經驗豐富的“老兵”開很多很多工資，來保證業務進行順利。
話雖這麼說，總會有少數工程師最終決定有一天掛斷IDE，並開始過渡到管理層。
挺噁心的。
太長不看版：反正現在就我來說，轉管理層這條路是可選的，但絕對不是適合所有人的。
如果你具有紮實的溝通技巧，並且確實願意開會開一整天（這樣你可以消除干擾、幫助隊友爭取更多時間來高效完成工作），那麼你進入管理層就是非常有意義的。
如果你由於其他任何原因轉行管理層（即使剛讀了我的博客文章，也因爲受到僱主的壓力、較高的薪水、害怕技術技能過時的焦慮等等），那你的日子可能就難過了。
回顧我的旅程，能從初級開發者過渡到高級開發者，歸功於我每週（在繁重的編碼任務之間）都試着花幾個小時專注於以下事件：
- 改進我們進行技術面試的方式，保證我們與候選人之間的溝通信噪比更高（如改善我們的面試問題、重新考慮我們的電子郵件模板、考慮是否要給面試者佈置線下筆試題、反思我們對工作的描述是否準確、我們向哪裏投放招聘廣告、換位思考如果我正在尋找工作會如何回覆該招聘信息、如何在候選人做出決定之前使其更深入地瞭解我們的公司文化和發展歷程等等）
- 與產品團隊合作，以更細緻的方式對即將開展的工作進行分類，從而使產品團隊和最終要去接收JIRA tickets的工程師之間的溝通更加順暢，而不需要磨嘰好幾個來回
- 組織團建活動和團隊聚餐
- 當CEO/CTO爲即將到來的季度制定的目標聽起來有點過於樂觀時，向他們提出提醒和意見，以免團隊其他成員受不了過分辛苦的工作而逃離你們公司
- 最好能每週與所有大的客戶進行一次確認電話（親自回答他們所有的技術問題，並確保雙方之間的關係保持健康）
- 用6個月的時間進行積極的安全審覈，不斷提醒客戶我們會認真對待他們的隱私，並在公司發展的每個檢查點努力完善我們的流程
- 找出其他開發人員在知識上的不足之處，然後讓他們查缺補漏（使用能激發他們學習興趣的方式）：如使用vim宏處理CSV文件、Linux終端中實用的短命令、高級SQL命令、如何使PR描述更具描述性、解釋負載平衡器如何工作、討論合併和重新定基之間的區別等
- 幫助設計團隊在花數小時將線框轉換爲高保真模型之前，先弄清楚哪些功能易於開發
- 改進我們的流程，讓其他部門知道何時會增加新功能（編寫更好的發行說明、在每週的內部產品演示中回答他們的問題、幫助他們編寫客戶能理解的外部文檔），因爲沒人知道的功能不會解決任何實際問題
上面的列表還可以一直一直往下寫，而其中大部分條目不需要用到Visual Studio。
幾年後，許多高級工程師走的路都是類似的。你可能在不知不覺中就變成了小領導，每天有6個人向你彙報工作。
原文鏈接：
https://medium.com/@jacobcomer/bridging-the-gap-between-junior-and-senior-engineers-571b2248fbb8