作者：丁儀

來源：https://chengxuzhixin.com/blog/post/30_sui_hou_de_fa_zhan_fang_xiang_he_tu_po.html

前些年，有人說程式設計師只能幹到 30，後來大家把年齡提到 35，最近好像又有提到 40 的跡象。最近 Python 創始人 Guido 入職微軟了。Guido 在 1989 年創造了 Python，無論從哪個角度看，都是絕對的高齡程式設計師了。

程式設計師是青春飯嗎

很多人都說寫程式碼最多到 35 歲，妥妥的青春飯，然而科學分析不這麼認為。《Is Programming Knowledge Related to Age?》論文對 1694981 名 StackOverflow 使用者的研究發現，程式設計師的平均年齡是 30.3 歲，其中資料清洗後參與分析的使用者是 84248 名程式設計師，平均年齡 29.02 歲。

在年齡分佈中，人數最多的是 25 歲，中位數是 29 歲。然而分析發現，程式設計師的能力從 25 歲左右開始上升，一直到 50 歲後才會開始下降。論文還研究了程式設計師對新技術的跟進，發現不同年齡的程式設計師對新技術的學習並沒有差太多。大齡程式設計師對某些新技術的學習甚至超過年輕程式設計師。所以論文得出的結論是，程式設計師的技術能力上升可以到 50 - 60 歲，並且大齡程式設計師跟進新技術的能力和年輕程式設計師相差不多。

從身邊的觀察發現，30 歲的程式設計師積累了大量經驗，可能才剛剛成為優秀的人才，架構設計能力、領導力需要大量的實踐積累，不是能夠輕鬆掌握的。網際網路是一個新興行業，大部分從業者都是後期加入的，平均年齡要低於其他行業。

30 歲後的職業規劃

一個程式設計師在 30 歲後，可能面臨技術專家、技術 Leader、架構師三個發展方向的選擇。

技術專家很好理解，在一個領域深耕，對業務和程式碼都有很好深刻的理解，經驗豐富，能夠用技術解決公司遇到的實際問題。成為技術專家需要大量的實踐積累，正常發展情況下差不多都要到 30 歲左右。正常來說，技術專家是人才梯隊中非常重要的角色，對技術方案設計有很大影響。

前幾天看到有個公眾號轉載一篇高併發的文章，一個看起來一年內工作經驗的作者展示了漏洞百出的技術方案，還能發上線，可見技術專家對團隊的重要作用。沒有技術專家的團隊，人才梯隊很難建立起來，團隊內成員的成長可能也會受影響。

技術 Leader 會開始涉及技術管理方面的事務。注意這裡是 Leader，不是 Manager。Manager 是管理者，而 Leader 更多是領導者。作為技術 Leader，需要重點保障核心業務、做技術建設、提升業務效果。為團隊設定合理的目標，做好排兵佈陣，協調各個團隊和資源。所以業內往往稱為“技術管理”而不是“管理”。

技術 Leader 比團隊其他同學視野更開闊，對長遠的發展趨勢看的更準，有技術前瞻性。雖然已經成為團隊中最牛逼的程式設計師之一，但是也要逐漸學會借他人之手寫程式碼，專注於寫程式碼的時間比以前減少很多，而這一點正是優秀程式設計師轉變為技術 Leader 所面臨的最大挑戰之一。

架構師是一個非常出名的稱謂了，然而卻很少有專門的架構師崗位。阿里前幾年有架構師崗位，不過現在也迴歸“技術專家”這樣的純技術崗位了。架構師必須是最出色的程式設計師，擁有技術深度和廣度，有系統性的認知和技術前瞻性。

架構師通常和技術 Leader 有部分重疊，尤其是在團隊規模比較小的時候，兩者往往是同一個人。隨著軟體規模的增大，架構師開始在比技術 Leader 更高的高度上看待問題，這時候架構師和技術 Leader 開始分化為不同的人。架構師也不一定是公司任命的權威領導者，但是在團隊內部通常有非權威領導力，是團隊內部非常信任的技術領導者。

這三個發展方向可能會有重疊，對個人來說，還是最好想清楚側重點是什麼。

掌握軟體系統方法論

越是到職業發展的後期，越不能依靠程式碼本身。所有人都使用著同樣的開發語言，掌握著同樣的語法和指令碼。作為執行者很難體現出優勢，總不能說掌握的語法和二方包比別人多吧。優秀的程式設計師能比別人寫出更好的程式碼，主要還是在如何寫程式碼，以及程式碼背後的思考，也就是程式設計師的方法論。

方法論英文單詞是 methodology，也就是說它是關於方法(method)的學問，是關於人們認識世界、改造世界的方法的理論，是人們用什麼樣的方式、方法來觀察事物和處理問題。簡單地說，方法論是成熟的思維方式。

成熟的方法論有很多。前面文章提到的黃金圈法則，是思考問題、分析問題的方法論。領域驅動設計是架構設計方面的方法論，能夠幫助解決複雜問題。金字塔原理，是思考問題、解決問題、寫作、PPT 演示方面的方法論。系統化思維，是對複雜系統如何觀察和分析的理論，也能指導設計複雜系統。

我們常說的“抓手”、“賦能”、“共建”、“打法”、“對焦”等看起來比較虛的東西，其實就出自於方法論，是方法論中對具體事物和行為背後的客觀規律的總結。脈脈上很多人對此嗤之以鼻，成為了大家吐槽的物件，但是這都是很成熟的概念。

如果長期停留在使用框架的層面，容易陷入工具誤區，把使用框架當做技術，思維方式也被侷限在框架裡。會有一種技術很牛逼的錯覺，但是和其他人相比，卻沒有多少優勢，容易被更年輕更有活力的後輩取代。

形成自己的方法論

方法論的形成需要長期的積累，可以借鑑學習圈理論。學習過程由具體經驗、反思觀察、抽象概括、主動實驗四個階段，並形成一個閉環。首先學習一個具體的東西，然後停下來對自己的經歷進行復盤和思考，再對學習的內容進行抽象，概括成為真正能理解、能吸收的知識，最後再把學習的概念和理論應用於實踐並解決現實的問題，如此往復迴圈。

定向鑽研一個技術方向，可以加深技術深度，有助於形成方法論。比如，可以定一個目標，讓需求上線的時間縮減一半或者同樣成本支撐的需求數量翻倍。接下來就需要思考什麼樣的架構設計能夠支撐翻倍的效能，很多情況下都會走向配置化、提升複用、熱部署等，接下來你就可以總結出你的方法論了。

親自設計一個框架，也是一個不錯的選擇。既能在縱向深挖，又會有橫向拓展的機會。不過這樣的嘗試一定要以足夠的經驗積累為前提，否則可能走入誤區。跳出日常的習慣，拔高視野，很快就會有領悟，甚至推翻低層次的認知。

覆盤和反思有助於改造認知，實現認知升級。推薦使用黑匣子思維，記錄下過程中的思考和問題，能夠幫助更好地覆盤。關於覆盤的方法，推薦閱讀《覆盤:對過去的事情做思維演練》，書中講了很多覆盤的方法和技巧，是關於覆盤的方法論。

經過思考和訓練，你會得到很多經驗和認知，會形成自己的思維方式，能夠對一類問題形成體系化的深度思考，然後再總結出一些概念進行抽象，使經驗適用於更廣闊的共性問題，就實現了經驗到理論的昇華。把自己的理論應用於實踐，觀察實際效果，對比之前的預期，再領悟新的經驗和思考，迴圈往復，就形成了方法論。

以上就是本文的全部內容了，與君共勉。

微.信.搜.一.搜.程式之心，每週一三五原創更