淺談一個程序員「看得見的成長」

文 | 尹競成

網易雲商 CTO

寫在前面

一直想和你們一塊兒探討研發同窗成長相關的內容。但願本身不要寫出一篇雞湯文。

成長是一個永恆的話題。無論是初入職場的新人，仍是在職場摸爬滾打多年的老兵，每一個人都但願可以不斷成長。對研發同窗來講，成長意味着須要有更寬廣的技術視野，在一個或者多個技術領域有足夠的技術深度，須要有本身的核心競爭力。這幾年來我面試了不少人，發現入行時間徹底不足以衡量一位同窗的能力，中庸無爲的職場老人並很多見。那麼，是什麼致使了你們在數年內差距變得如此之大呢？我以爲大概能夠歸納爲幾下幾點。

終身成長的心態

《終身成長》這本書寫得很是好。做者定義了兩種思惟模式，一種是固定型思惟。就是認爲本身的能力是固定不變的。擁有固定思惟的人會不斷和周圍的人相比較、急於證實本身的能力。一旦失敗，就會認爲本身是一個沒有能力的人，或者缺少在這方面的天賦，從而放棄努力；

另外一種是成長型思惟，就是認爲本身的能力是能夠經過努力來培養的。擁有成長性思惟的人遇到困難時，就會以學習的心態去積極面對。即使是遇到了挫折，也不會放棄，而是不斷地學習，發展能力，找到解決問題的方式。

前些天我面試了一個Java開發工程師，他跟我說他以爲本身是一個內向的人，懼怕和同事討論問題，擔憂本身說錯了影響同窗對本身的見解。我說，我能夠給你一個建議嗎？首先，不要給本身打標籤，絕大多數人都既不外向、也不內向，你們都處於中間水位。一旦給本身打了「內向」這樣一個標籤，就會下意識地限制本身交流和溝通。其實在和他的交流過程當中，我並無以爲溝通表達能力有什麼問題。

其次，擔憂本身說錯、總但願證實本身，這是典型的固定型思惟。通過本身的思考、得出結論並和你們討論，就算有不缺漏又有什麼關係？互通有無、共同促進纔會讓討論更有效果。（但願我不成熟的「診斷」可以幫助到這位同窗）

終身成長最重要的是可以找到本身的方向，看到本身的缺點和不足，制定計劃，付諸實踐，覆盤校準，而後優化計劃。不強求一朝一夕的收穫，可是堅信點點滴滴、日積月累量變會引發質變。

坊間傳聞「程序員35歲前須轉管理」，這個說法就很反終身成長。

我一直以爲這個說法的興起，一方面是由於咱們有程序員這個工種的年頭還太少、35歲以上的程序員同窗還不夠多，另外一方面是固定型思惟的做祟。

2007-2008年我在東京的一家小公司裏工做，裏面有位白髮蒼蒼的老大爺，偶爾跑跑客戶，大部分時間和咱們一塊兒寫代碼，寫得不亦樂乎。目前Linux內核維護者主要仍是即將年滿51歲的Linus和一些50或60後的老程序員。

程序員職業生涯能夠很長，關鍵在於你是否願意終身學習。

互聯網的技術更新很是快，可能偏底層一些的技術生命力長一些，越接近用戶端的技術更新就越快，須要咱們不斷保持對前沿技術的關注、不斷學習。固然，不少技術底層的原理是相通的，積累的經驗能夠做爲學習下一項技能重要的加速度。多年經驗的程序員不管學任何新技能，都會比畢業生要快不少，包括知識轉換率、架構理解等問題，以及對新知識和技能的運用、問題排查等等。

網易一直強調匠心精神，我以爲這一點對成長來說也很是重要。越用心，對本身要求越高，進步越快。

好比寫一個函數，是否是代碼行數能夠再少一點、執行效率能夠再高一些；寫網絡協議，傳輸內容是否能夠再壓縮一些；作業務開發的同窗，是否是能夠把業務邏輯層次抽象清楚，成爲模塊化可用複用的能力。一旦養成這樣的思考習慣，就會有動力去學習一些本質的東西，如操做系統、內存模型、設計模式等等，技術能力就會不斷獲得提高。

良好的學習方式

針對性的學習

首先咱們得肯定一個目標領域，是Java語言仍是NLP算法。而後給本身制定一個詳細的學習計劃。最近面試他人的時候我常常會問一個問題：將來一年內你打算學習些什麼？大部分人都只會說，接下來會學習DDD開發模型或者是xx中間件的底層原理。我以爲這隻能算是學習方向，並不能算是一個學習計劃。只有少數候選人會告訴我，他們會學習到什麼程度、如何檢驗本身的進展。而每每這樣的候選人對知識和技能的掌握上都遠好於前一種。

程序員的學習會有兩個維度，廣度和深度。不少人都有疑問，先廣度再深度，仍是反過來。我以爲本質上並無衝突，只是咱們在不一樣階段學習的重心有所側重而已，而且應該是一個交替往復的過程。時間和精力老是有限的。對剛畢業或者剛入門的同窗，我建議能夠廣度優先，多接觸一些領域、多瞭解一些內容。而後找到一個方向，在一個領域很是深刻地進行學習，瞭解底層原理，學習其核心設計思想。

精通一門語言是很是重要的。每一門語言都有本身的優缺點，精通意味着能夠找到合理的使用方式，把它的優勢發揚光大，經過一些設計模式彌補它的缺陷和不足，從而下降使用成本，合理地解決複雜問題。

關聯性是人類創建認知很重要的一個因素，咱們須要刻意強化這種關聯性。咱們在學習一項新的知識和技能的時候，每每會用已有的知識去認識未知。所以對一門語言的深刻掌握，有助於咱們快速學習新的語言，而不用每次都從HelloWord開始。

我在網易的前些年，無論是作客戶端軟件仍是作遊戲，一直在使用C++。後面因爲業務和行業的變遷須要學習C#、Python、Java等語言，經過對語言特性的類比和概括，學習起來就很是快了。

刻意練習

小時候老師常常說：好記性不如爛筆頭。意思就是要多寫、多練。程序開發也是這樣。即便是記憶力再好的人，看過的內容若是一直不用，很快也就變得模糊甚至完全忘記了。因此必定不能眼高手低。新手能夠從模仿開始，進階時給本身出題。

把學到的新知識和新技能用於工做實踐中，是一種很好的方式。固然也要看團隊的業務和技術成熟度，對新技術棧的包容性。咱們團隊對技術持很是開放的態度，鼓勵你們學習、使用新東西。（歡迎投簡歷哈！)

刻意練習這個詞最近幾年特別流行，不少地方都在講。刻意練習質疑了「只要通過一萬小時的鍛鍊，任何人均可以從平凡變得超凡」的說法。沒有思考和總結的機械式練習，即便超過1萬小時或許仍是很平庸。刻意練習，須要找到好的導師，有目標、有計劃、有覆盤。

開源社區的流行和壯大爲咱們閱讀和學習優秀的代碼提供了很好的平臺，也讓咱們有更多練習的場景。有些同窗說咱們996哪來的時間去開源社區添磚加瓦？那就在工做中多思考、多覆盤，適時重構本身之前的老代碼，不斷優化。再說了，時間擠擠老是有的。

不要抗拒業務開發

不少同窗看不上業務開發，以爲寫業務代碼很low，沒有技術含量，而更願意去作中間件開發、架構設計等。我以爲這種想法是不對的。

技術的進步歷來都是爲了解決業務問題。好的業務代碼必定是有技術含量的，好比能夠經過封裝和抽象使系統更好維護、更具擴展性，經過可插拔可配置式的方式更快速實現業務邏輯，等等。好的業務架構設計既須要豐富的經驗，又須要充分的技術底蘊。

可是隻作好業務開發又是不夠的。一樣作業務開發，有些同窗很快成長起來，負責了更大的模塊，承擔了更大的責任，有些同窗還在原地踏步。差距在哪裏呢？我以爲除了上文所說業務封閉和抽像以外，比較重要的是，須要本身主動往前邁一步。

去了解本身負責的模塊以外的模塊實現和業務邏輯，學習整個系統的架構設計，瞭解系統的上下游，參與運維穩定性和系統優化性的工做，和產品團隊多交流溝通業務設計。只有這樣，纔能有更全局的視角，設計更完善的系統，更快地成長。

程序員的軟實力

永遠不要忽視對本身軟實習的修煉。對程序員軟實力的要求，和其它工種並無什麼不一樣。冰下山的那些能力，包括自信、堅韌、皮實、誠實、責任心，等等。鋪開來說真的成了一篇雞湯文啦，哈哈。我只講講很是重要、實際中又容易被人無視的一點：同理心。

同理心可讓交流更加有效率。好比在和別人交流的時候，夾雜着一堆技術語言、甚至是本身項目中的代號，口若懸河、滔滔不絕，而對方卻一臉懵圈。這種時候不能責怪別人的理解能力差，只能說你沒有辦法把程序員思惟，包裝成對方也能聽懂的「人話」。

前幾年還在雷火遊戲部的時候，帶個人領導要求咱們若是有團隊成員須要你的協助，那麼請放下你手頭本身的工做，優先處理其餘同窗的請求。我以爲這是對同理心很好的一種詮釋。每一個人都優先配合別人，會讓整個團隊的流程和運轉更加圓潤，更加有效率。我如今也這麼要求個人團隊。

同理心會改變咱們思考問題的角度和立場。

一開始涉及跨團隊合做的時候，本能地會從自身和本身團隊的角度出發考慮，劃定好邊界，回頭想一想這種時候每每合做起來會有不少摩擦和不理解。

後來，會從本身和對方出發去考慮問題，從雙方雙贏的角度去設計方案和推進問題解決，這個時候你們就能比較愉快地合做了。

再後來，會從項目、部門甚至是公司的角度去考慮一些問題的解決方案，更長遠的規劃和設計，而不只僅是眼前的利害得失。

有了這種視角，看問題就會更宏觀，每每也更能找到問題的切入點。今年網易集團升級了企業文化，其中很重要的一點就是要和用戶（客戶）在一塊兒，站在客戶的視角去作產品、作運營，去幫助客戶內生成長。

不知是否寫得有些空泛。但願能和你們多討論。寫在最後，「改變世界最快速的方式是改變本身」，你們多讀書、多思考、多總結。