程序員是青春飯嗎？30歲後的發展方向和突破

做者：丁儀

來源：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 演示方面的方法論。系統化思惟，是對複雜系統如何觀察和分析的理論，也能指導設計複雜系統。

咱們常說的「抓手」、「賦能」、「共建」、「打法」、「對焦」等看起來比較虛的東西，其實就出自於方法論，是方法論中對具體事物和行爲背後的客觀規律的總結。脈脈上不少人對此嗤之以鼻，成爲了你們吐槽的對象，可是這都是很成熟的概念。

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

 

造成本身的方法論

方法論的造成須要長期的積累，能夠借鑑學習圈理論。學習過程由具體經驗、反思觀察、抽象歸納、主動實驗四個階段，並造成一個閉環。首先學習一個具體的東西，而後停下來對本身的經歷進行復盤和思考，再對學習的內容進行抽象，歸納成爲真正能理解、能吸取的知識，最後再把學習的概念和理論應用於實踐並解決現實的問題，如此往復循環。

 

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

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

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

通過思考和訓練，你會獲得不少經驗和認知，會造成本身的思惟方式，可以對一類問題造成體系化的深度思考，而後再總結出一些概念進行抽象，使經驗適用於更廣闊的共性問題，就實現了經驗到理論的昇華。把本身的理論應用於實踐，觀察實際效果，對比以前的預期，再領悟新的經驗和思考，循環往復，就造成了方法論。

 

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

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