1. 寫在前面為什么要分享這條路這個標題看起來平平無奇但我實實在在地想把它寫給每一位正在屏幕前猶豫、焦慮、或者正準備轉(zhuǎn)行做技術的同學。我是從二流院校本科畢業(yè)第一份工作在一家不到二十人的小公司從寫后端接口到部署服務器再從帶小團隊到做技術負責人前前后后折騰了快十年。今天這篇文章不吹不黑不講那些天賦異稟三個月進大廠的神話只講一個普通人怎么靠方法和堅持一步步走穩(wěn)工程師這條路。很多人問過我最多的一句話是現(xiàn)在入行還來得及嗎我的回答從來都是同一句——工程師這個職業(yè)拼的不是天賦而是學習能力和解決問題的耐心。你可以沒有名校背景可以沒有競賽獎項但你必須有一份獨立把事做成、把問題拆開、把代碼跑起來的能力。這篇文章適合剛?cè)腴T的學生、正在找工作的應屆生、想轉(zhuǎn)行做技術的朋友也適合剛工作兩三年、正在迷茫期的初中級工程師參考。我會從成長路線的整體規(guī)劃、技術棧和學習方法、從學生到職場人的關鍵轉(zhuǎn)變、軟技能提升以及我踩過的那些坑五個方面展開盡量講得具體、可落地每一條都有實際案例支撐。你有時間可以一口氣讀完沒時間可以先收藏按章節(jié)對照自己的階段去查漏補缺。2. 工程師成長的整體認知與路徑設計2.1 工程師的四個成長階段你現(xiàn)在在哪一步很多新手對工程師職業(yè)最大的誤解就是覺得“寫好代碼好工程師”。實際上代碼能力只是工程師能力的其中一個維度。我更喜歡把工程師的成長分成四個階段你可以拿這個框架來對照自己當前的位置。第一階段是執(zhí)行者也就是剛?cè)肼殘龅?-3年。這個階段的核心任務是把交代的任務做好代碼寫得清晰、可靠能按時交付。你不需要操心架構(gòu)設計也不需要對業(yè)務結(jié)果負責但需要養(yǎng)成好的編碼習慣和嚴謹?shù)墓こ藤|(zhì)量意識。第二階段是解決者大致對應工作3-5年。這個階段你不再只被動的執(zhí)行者而是開始主動思考“為什么這樣做”“有沒有更好的方案”。你會承擔模塊級別的設計工作開始參與技術選型、接口設計、性能優(yōu)化也需要具備在沒人指導的情況下獨立排查問題的能力。第三階段是賦能者大概5-8年。這時候你的產(chǎn)出不再只是你自己寫了多少代碼而是你能讓整個團隊產(chǎn)出的效率和質(zhì)量提升多少?？赡苁悄阍O計了一套代碼規(guī)范可能是你推動了一個工具鏈的建設也可能只是你沉淀了一套團隊內(nèi)部的排障手冊。衡量標準從“我能寫多快”變成了“團隊能寫多快”。第四階段是骨干或?qū)＜?年以上。這類人往往是團隊里最后兜底的那個。別人解決不了的問題你來解決別人看不清楚的方向你來判斷。你可能不寫太多業(yè)務代碼但你對系統(tǒng)的理解、對風險的前瞻判斷對團隊來說是不可替代的。這個框架不是我自己瞎編的很多技術管理類的書里都有類似模型。關鍵是你要知道每個階段的核心目標是不一樣的如果你都工作5年了還在拿“我加班多、代碼寫得快”來說事那說明你還在第一階段原地打轉(zhuǎn)這時候就該有意識地往更高階段去跨越了。2.2 廣度優(yōu)先還是深度優(yōu)先一個矛盾的平衡題幾乎每一個人都問過我我應該先在某個方向挖得很深還是什么東西都了解一點這個問題沒有標準答案取決于你處在哪個階段以及你的目標是什么。我的建議是前三年以深度為主廣度做輔助補充3年后再根據(jù)職業(yè)方向逐步打開廣度。為什么這么說因為深度是你建立專業(yè)自信、獲得第一份認可的基礎。一個剛畢業(yè)的新人如果能在一個技術點上鉆研得比周圍人都透比如把MySQL的索引優(yōu)化玩明白或者把JVM的調(diào)優(yōu)參數(shù)研究清楚你就有了自己的標簽和差異化優(yōu)勢。公司面試時需要的也正是這種“在某一點上拿得出手”的人。三年之后你開始帶項目、帶新人這時候廣度就開始變得重要了。你需要理解前端同事在說什么需要知道運維那邊的部署流程需要了解產(chǎn)品經(jīng)理為什么要做這個功能。廣度不是讓你每個領域都成為專家而是你要有足夠的知識儲備去理解協(xié)作方和判斷全局。我踩過的一個反面例子是工作前五年我始終悶頭寫后端代碼對前端的知識近乎空白。結(jié)果有一次要獨立負責一個全棧小項目前端部分完全抓瞎臨時抱佛腳學了半個月Vue交付質(zhì)量慘不忍睹。那次經(jīng)歷讓我認識到廣度不是用來炫耀的而是為了在跨團隊協(xié)作和獨立交付時不自斷一臂。2.3 目標導向的反推法先看終點再定路線做職業(yè)規(guī)劃最容易犯的錯誤是一頭扎進學習里學到哪算哪。但更高效的方式是從目標反推路徑。你要先想清楚三五年后你想成為一個什么樣的人是想做技術專家還是想走技術管理路線或者是想自己創(chuàng)業(yè)做獨立開發(fā)者這三個方向?qū)δ芰?cè)重點的要求是很不一樣的。技術專家路線核心要打磨的是單點深度、源碼閱讀能力、系統(tǒng)設計能力技術管理路線更看重的是溝通能力、項目管理能力和業(yè)務敏感度獨立開發(fā)路線則要求你具備全棧能力、產(chǎn)品思維和運營推廣的基礎認知。你可以用一張紙把目標拆解成“能力清單”再對照清單去決定每一階段要學什么、做什么項目、補什么短板。我當時給自己定的中期目標是“三年內(nèi)成為團隊里后端最靠譜的人”。于是我把目標拆成了三個部分一是把Java語言本身和JVM機制吃透二是把數(shù)據(jù)庫和緩存相關的高頻問題掌握扎實三是至少完整參與兩次從零到一的項目開發(fā)。事實證明這個拆解方向?qū)髞淼拿嬖嚭蛯嶋H工作幫助都很大因為面試官問到的內(nèi)容幾乎都能映射到我當時設定的能力清單上。3. 技術棧選擇與高效學習方法3.1 語言和方向怎么選興趣不是唯一標準很多人在入門時會糾結(jié)我應該學Java、Python、Go還是前端、后端、算法我的建議是不要單純憑興趣來選而是結(jié)合三個維度去判斷。第一是市場供需。你可以在招聘網(wǎng)站上看一看你所在城市或者你想去的城市哪種崗位需求量最大、招聘門檻最友好。第二是技術生態(tài)。生態(tài)豐富意味著你遇到問題時更容易搜到答案也更容易找到成熟的第三方庫。第三是遷移成本。不同語言之間不是完全互通的但編程思維是相通的。其實你先熟練掌握一門語言的核心機制再學第二門時會快很多。有一個很現(xiàn)實的規(guī)律是后端開發(fā)崗位的需求量長期穩(wěn)定Java在國內(nèi)的生態(tài)和崗位量都很龐大Go在云原生領域增長很快Python在數(shù)據(jù)分析、人工智能方向占優(yōu)勢。前端領域React和Vue兩分天下。算法崗門檻高、崗位數(shù)量相對有限。如果你目標是盡快入行、穩(wěn)住職業(yè)基本盤我建議從后端開發(fā)入手Java或Go任選其一如果你對界面、交互更有興趣前端也是不錯的選擇。我不建議一上來就選一個非常小眾的冷門方向比如某些偏門框架或者深耕多年的專屬語言除非你確實有平臺資源和堅定的信念。對于大多數(shù)普通人來說選擇市場驗證過的成熟路線是降低風險最樸素的手段。3.2 學習中的三大方法費曼、刻意練習和項目驅(qū)動可能你已經(jīng)聽過很多學習方法論了但真正有效的就那幾樣我把它們串成一套適合工程師的組合拳。首先我用得最多的是費曼學習法。具體操作是每學完一個重要知識點比如“TCP三次握手為什么是三次”我就假設自己正在給一個完全不懂的人講這個概念用大白話寫在文檔里如果講到一半卡住了說明這個知識點我還沒真懂就回去重新查資料。后來這個習慣延伸成了我寫作和培訓分享的底層能力對加深理解效果顯著。其次是刻意練習。工程師的刻意練習不是一遍一遍寫hello world而是針對自己的薄弱點做專項訓練。比如你覺得SQL查詢優(yōu)化不行那就不要混在日常業(yè)務代碼里隨意寫而是專門花一個周末找10道不同類型的慢查詢案例一道一道分析執(zhí)行計劃、調(diào)整索引、驗證效果。這種針對性練習的產(chǎn)出速度和效果遠好于漫無目的地刷視頻課。最后是項目驅(qū)動學習?？磿匆曨l學到的東西都是“假性掌握”只有當你真的做出一個能跑起來的系統(tǒng)時那些知識才真正屬于你。你可以定一個目標比如“做一個帶用戶注冊、登錄、發(fā)帖、評論功能的小社區(qū)”然后在這個項目里主動加入你剛學會的技術點比如用Redis做會話緩存、用消息隊列做通知異步化。一個完整的項目做下來你掌握的內(nèi)容跨度可能比看十本書還要大。3.3 我需要看書嗎視頻、文檔和源碼怎么配合市面上學習資料太多很多同學陷入“收藏從未停止學習從未開始”的怪圈。我的經(jīng)驗是不同類型的資料有不同的用途關鍵是要配合使用而不是只依賴其中一種。視頻課適合入門和建立整體認知尤其是那些由一線工程師錄制的實戰(zhàn)課可以幫你快速了解一個領域的全貌。但視頻課的缺點是信息密度偏低容易讓人產(chǎn)生“我聽懂了我會了”的錯覺所以看完一個章節(jié)后必須立刻動手寫代碼驗證。官方文檔是最權威的參考資料但新手直接讀文檔往往抓不住重點建議把它當“字典”來查而不是當“教材”來啃。源碼閱讀是進階階段的重要功課不要從那些巨型項目開始讀而是從你日常使用的小型開源庫入手比如一個JSON解析庫、一個HTTP客戶端庫代碼量幾千行的規(guī)模剛剛好。我的習慣是“視頻入門文檔查證源碼深化”三步走。比如學一個新框架先花兩三天看一個不錯的實戰(zhàn)視頻對整體流程有個概念接下來在工作中實際使用時遇到問題第一時間查官方文檔等用熟了之后再挑一兩個核心模塊去看源碼實現(xiàn)理解框架設計者的思路。這樣一輪下來你對這個技術的掌握程度就會明顯超過平均水平。4. 從學生到工程師求職與入職實戰(zhàn)解析4.1 簡歷不是履歷流水賬用項目結(jié)果說話很多應屆生和轉(zhuǎn)行同學寫簡歷最大的問題就是把自己做過的事寫成了崗位JD職位描述比如“負責XX系統(tǒng)的開發(fā)與維護”這類描述幾乎沒有信息量。正確的寫法是以項目為單元用結(jié)果說話讓面試官一眼就看出你做了什么、做到了什么程度。我建議簡歷里的每個項目都按四層結(jié)構(gòu)來寫項目背景為什么做、你的職責具體負責哪塊、技術方案用了什么技術、怎么設計的、結(jié)果數(shù)據(jù)性能提升多少、支撐多大訪問量、上線后穩(wěn)定性如何。舉個例子與其寫“負責用戶模塊開發(fā)”不如寫成“設計并實現(xiàn)了用戶注冊登錄模塊基于Spring Security整合JWT實現(xiàn)無狀態(tài)鑒權支持每日約2萬新增用戶登錄接口平均響應時間低于200毫秒”。此外簡歷上不要寫與自己能力不匹配的內(nèi)容。面試官順著你的簡歷深挖時一旦發(fā)現(xiàn)你寫的技術棧自己根本講不清楚比不寫扣分還嚴重。你寫在簡歷上的每一條都要準備好被追問到細節(jié)這個原則我面試過很多人屢試不爽也幫你篩掉了大量靠包裝簡歷混進來的候選人。4.2 面試準備八股文之外更要練系統(tǒng)設計國內(nèi)技術面試比較看重基礎知識和“八股文”式的問題比如HashMap原理、并發(fā)機制、TCP握手等等。這些當然要準備但我想提醒你的是只背八股文是不夠的現(xiàn)在越來越多的公司在面試中加入了系統(tǒng)設計題比如“如果讓你設計一個短鏈接系統(tǒng)你會怎么做”。這類題目考的不是你會不會某個API而是你分析問題、拆分模塊、權衡方案的綜合能力。準備這類問題可以先從一套固定的答題框架練起先澄清需求預估QPS是多少數(shù)據(jù)量多大再做模塊拆分短鏈接生成、存儲、跳轉(zhuǎn)、統(tǒng)計再選型存儲MySQL還是Redis是否需要緩存最后補充容災和擴展方案。哪怕你最終的方案不完美只要邏輯清晰、考慮全面面試官也會給你不錯的評價。面完試之后一定要做復盤。把面試中被問到的問題記錄下來挨個查漏補缺。我當年準備了一套“錯題本”把每一次面試答得不好的問題都整理成一篇筆記。幾輪面試下來這套錯題本的價值甚至超過了專門的復習資料因為它是完全針對你個人薄弱點的定制化方案。4.3 入職第一年如何快速建立信任和存在感順利拿到offer只是開始入職后的前半年才是決定你在團隊位置上限的關鍵階段。很多新人入職后容易犯兩個極端一個是太靦腆有問題不敢問自己悶頭憋三天另一個是太冒進沒理解需求和歷史背景就亂提重構(gòu)方案。這兩個極端都會讓團隊對你產(chǎn)生不信任。我的建議是入職頭一個月先別急著表現(xiàn)重點做三件事第一把項目代碼從入口到出口完整走讀一遍畫一張架構(gòu)圖第二把團隊的技術文檔、需求文檔、排期流程都看一遍理解團隊怎么協(xié)作第三找到團隊里最靠譜的1-2個同事建立良好溝通關系遇到問題先自己想超過30分鐘想不出來再找他們溝通。等入職一個月后你可以開始主動爭取一些“小而確定性高”的任務比如修一個無關緊要的bug、補充一個單元測試、優(yōu)化一處代碼注釋。這些小事技術含量不高但能幫你積累團隊的信任積分。記住一個樸素的道理團隊只有先相信你能做好小事才會放心讓你做大事。這個信任積累的過程急不來但一旦建立了你后續(xù)的成長速度會非?？?。5. 軟技能與工程素養(yǎng)決定你能走多遠的隱藏因素5.1 溝通能力工程師最容易忽略的必修課技術圈有個普遍的現(xiàn)象很多工程師技術能力很強但一到跨部門溝通就抓瞎要么沉默不語要么說話全是術語對方根本聽不懂。你在職業(yè)生涯初期可能感受不到溝通能力的價值但到了帶項目、做技術方案的階段溝通能力的差距會被急劇放大。我自己的體會是工程師溝通中最重要的一件事是區(qū)分事實和觀點。討論技術方案的時候不要只說“我覺得這樣好”而是要把依據(jù)列出來這個方案的優(yōu)勢是什么代價是什么對比其他方案的差異在哪里可能出現(xiàn)什么風險。用數(shù)據(jù)和事實說話不僅能減少無謂的爭論還能讓團隊更愿意采納你的方案。另一個實用的技巧是面向聽眾調(diào)整表達方式。跟技術同事討論可以放開了聊技術細節(jié)跟產(chǎn)品經(jīng)理溝通重點說清“能做到什么效果、需要多少時間、有什么風險”跟非技術背景的領導匯報就只講結(jié)論和關鍵數(shù)據(jù)細節(jié)放到附錄里。這個能力看起來簡單但你在實際工作中會發(fā)現(xiàn)能把技術問題講得讓外行聽懂是一項非常稀缺且受認可的能力。5.2 代碼評審與文檔沉淀把隱性知識變成團隊資產(chǎn)提到代碼評審很多初級工程師的第一反應是抵觸覺得是在挑自己的毛病。但等你工作幾年后回過頭看會發(fā)現(xiàn)代碼評審其實是成長速度最快的場域之一。每次評審別人代碼的時候你都能看到不同的實現(xiàn)思路和編碼習慣每次別人評審你的代碼時對方指出來的每一個問題都是你認知盲區(qū)的直接暴露。我建議你主動爭取參與團隊里的代碼評審不要只做“已閱”的那種參與者而是認真看改動邏輯、提出具體問題。哪怕你的問題最后被證明是誤解也是一次深入的交流學習。時間久了你在團隊里的技術影響力和話語權會自然而然地提升。文檔這件事也是同樣的道理。很多工程師不愛寫文檔覺得寫代碼就夠了。但實際上一份好的技術文檔能幫團隊剩下大量溝通成本。一個簡單的經(jīng)驗是你花一小時寫一份排障文檔可能會為未來某個深夜排查問題的同事省下一整夜。而且文檔沉淀的過程也是你梳理自己思路、檢驗理解深度的過程。我現(xiàn)在帶團隊時會把文檔產(chǎn)出量作為考核工程師的重要指標之一因為一個能寫出清晰文檔的人大概率也是一個思路清晰的人。5.3 技術債務與質(zhì)量意識慢就是快快就是慢剛工作的時候我為了趕進度經(jīng)常寫出“先能跑以后再優(yōu)化”的代碼。這些代碼當時確實幫我快速交付了功能但幾個月后往往變成了一碰就炸的雷區(qū)每次改動都要小心翼翼效率反而更低。這就是典型的技術債務借的時候輕松還的時候連本帶利。我給新人的建議是在寫每一行代碼之前都問自己三個問題這段代碼三個月后我還能看懂嗎如果有人接手他能快速理解嗎有沒有更簡單但類似效果的做法這三個問題聽起來很基礎但如果你真的每次都認真想一遍代碼質(zhì)量會明顯高于同齡人。當然技術債務也不是完全不能有。有些業(yè)務場景要求快速上線驗證這時候可以接受適當?shù)暮喕瘜崿F(xiàn)但必須在代碼里寫清楚TODO和原因并且記在你的待辦清單里。關鍵區(qū)別在于有意識地欠債并計劃歸還和無意識地堆垃圾代碼是完全不同的兩回事。前者是技術決策后者是職業(yè)素養(yǎng)問題。6. 常見問題與避坑指南我踩過的一些坑6.1 新手入職后最容易踩的5個坑我把這些年見過新人踩得最多的問題整理成了一份避坑清單不分崗位通用分享給各位第一不問清楚需求就動手寫代碼。很多新人接到任務后怕顯得自己笨不敢多問按自己的理解悶頭就寫結(jié)果做出來的東西和需求方想的完全是兩回事。我的建議是接到任何任務先用自己的話復述一遍需求找對方確認再開始動手。這個確認過程最多花五分鐘卻能省下后面幾天改返工的代價。第二代碼只保證能跑不考慮異常和邊界。一些新人寫完代碼測了正常流程就提交了但一到線上就崩。真實世界的數(shù)據(jù)永遠是臟的、亂的、不可預測的。寫代碼時多想想如果這個參數(shù)傳空怎么辦如果這個接口超時怎么辦如果用戶惡意輸入怎么辦這些邊界情況的處理才是區(qū)分初級和資深工程師的重要標志。第三遇到問題不搜索就到處問人。問人本身沒錯但如果每個問題都不經(jīng)過自己的思考和嘗試就去問同事很快就會不耐煩。我建議一個原則遇到問題先自己搜索嘗試30分鐘然后把嘗試過的方案記錄下來再帶著這些記錄去問人。這樣做的好處是即使你最終沒解決你也能把問題描述清楚對方幫你時效率也高。第四忽視測試的價值。在很多公司初級工程師往往是寫業(yè)務代碼的主力測試容易被當成“額外負擔”跳過去。但如果你能養(yǎng)成寫完代碼順手補上核心用例的習慣你的代碼質(zhì)量會顯著提升而且這個習慣在面試和晉升中都會成為你的加分項。第五頻繁切換技術方向什么都學什么都沒學精。每半年換個熱門方向最后簡歷上寫了一大堆技術但沒有一個能經(jīng)得起深挖。選擇方向后至少要在一到兩年內(nèi)持續(xù)深耕建立自己的護城河。6.2 領導把需求說得不清不楚怎么辦這其實是職場里一個非常高頻的問題值得單獨拿出來聊。很多時候不是領導故意不清不楚而是他自己也還在探索中或者他默認你已經(jīng)掌握了背景信息。這時候你要做的不是抱怨而是把模糊變成清晰把被動變成主動。你可以把不清晰的需求拆成幾個具體的子問題逐一找相關人員確認。比如“這個功能的核心用戶是誰”“優(yōu)先做哪些場景”“當前最關鍵的指標是什么”這些問題看起來簡單卻能幫你快速鎖定工作的重點。如果你問了之后還是覺得不清不楚那你可以做一個最小方案給領導看用可視化的原型或者簡單的demo來對齊認知比用文字來回溝通效率高得多。記住一個核心心態(tài)把需求變清晰是你的職責之一不是額外負擔。那些能把模糊需求梳理清楚的工程師往往在團隊里會逐步承擔更重要的工作。因為你不僅能執(zhí)行還能定義問題這種能力非常稀缺。6.3 技術選型糾結(jié)癥怎么擺脫“學哪個好”的焦慮后臺經(jīng)常有同學問我我現(xiàn)在糾結(jié)學A還是B怎么辦這類問題背后往往不是技術問題而是選擇焦慮。我的建議是把“學哪個”這種問題轉(zhuǎn)化為“我現(xiàn)在最需要解決什么問題”然后選擇能最快幫你解決問題的那個技術。我舉一個自己的例子曾經(jīng)有段時間我需要給團隊搭建一個內(nèi)部工具平臺在考慮用Python還是Node.js。我當時并沒有糾結(jié)太久因為團隊里后端是Java前端是Vue我選Node.js可以和前端共享語言生態(tài)減少團隊協(xié)作成本。這個理由跟Python好壞完全沒關系純粹是“解決當前問題的最佳選擇”。技術選型是有場景的脫離了具體場景談好壞基本都是耍流氓。如果你真的在兩個方向之間搖擺不定還有一個很實操的方法各花一周時間做一個同樣的小項目看看哪個方向你做得更順、更愿意繼續(xù)深入。真實體驗帶來的判斷遠勝于看網(wǎng)上各種對比文章帶來的紙上談兵。7. 長期主義與持續(xù)學習的幾個習慣7.1 每天留出45分鐘的“學習留白時間”很多工作多年的工程師都會發(fā)現(xiàn)一個扎心的事實工作之后的學習時間遠少于學生時代。白天被會議、需求、聯(lián)調(diào)占滿晚上回家只想躺著刷手機。但那些成長快的人往往都有一個共同的習慣——每天留出一段固定的、不受打擾的學習時間。我自己的經(jīng)驗是每天下班后留出45分鐘不做與工作直接相關的事情而是拿來擴充自己的知識邊界?？梢允亲x一篇技術博客可以看一個開源項目的最新進展也可以學一點軟技能相關的知識。關鍵是每天都要有形成習慣。別看每次只有45分鐘一年積累下來就是270多個小時足夠系統(tǒng)學習一個全新的方向。這個習慣還有一個意外的好處它能把你的注意力從“我今天又寫了多少行代碼”轉(zhuǎn)移到“我今天又學到了什么新東西”。長期來看后者才是工程師職業(yè)發(fā)展真正的復利。7.2 寫作與分享最被低估的成長杠桿如果你問我過去十年做過的最值得的投入是什么我的答案不是學了某個框架而是開始寫作和分享。一開始我只是在團隊內(nèi)部分享技術筆記后來開始在一些技術社區(qū)寫博客再到后來出去做技術分享這一路收獲遠超我的預期。寫作對工程師的價值至少有三個維度第一寫作會倒逼你把模糊的概念想清楚因為你想不清楚就寫不明白第二寫作會幫你建立個人品牌當你的文章被別人看到并認可時職業(yè)機會也會主動找上門來第三寫作是很好的知識復利手段你五年前寫的技術文章到現(xiàn)在可能還在被搜索、被收藏、被轉(zhuǎn)發(fā)這是任何短期投入都難比擬的。如果你不知道怎么開始我的建議是降低門檻先從“給自己寫筆記”開始再逐漸把自己的踩坑記錄、學習心得發(fā)布出來。不用追求文筆多么優(yōu)美工程師寫東西核心是把事說清楚。哪怕一篇文章只解決了一個具體問題也會有人因此受益。7.3 職業(yè)倦怠期怎么和自己和解再出發(fā)雖然這篇文章大部分篇幅在講“如何變得更強”但我也想聊一個相對沉重的話題——職業(yè)倦怠。做了多年工程師幾乎每個人都會遇到那么幾個時刻代碼寫煩了、業(yè)務沒有挑戰(zhàn)、感覺自己在重復勞動、升職遙遙無期。我第一次出現(xiàn)明顯倦怠感是在工作第四年那段時間每天上班做需求下班刷劇覺得日子過得像復制粘貼。后來我認真復盤了一下發(fā)現(xiàn)自己倦怠的核心原因是“沒有長進”。當一個人長期處在舒適區(qū)每天做同樣的事情大腦就會分泌出無聊和疲憊的信號。走出倦怠期我的經(jīng)驗是給自己找一個“新挑戰(zhàn)支點”?？梢允侵鲃咏邮忠粋€你從沒做過的任務類型可以是學一門與當前工作方向不同的技術也可以是嘗試帶一個新人。關鍵是打破原有的節(jié)奏讓自己重新感受到成長帶來的正反饋。如果嘗試了這些之后還是覺得不喜歡那也可以認真考慮換一個環(huán)境。工作換不換其實是次要的真正重要的是你要保持對世界的好奇和對自己成長的主導權。這條路沒有什么最終終點走好每一步時間自然會給你答案。根據(jù)我個人的觀察那些走得遠的工程師往往不是最聰明的那批而是最能堅持、最會總結(jié)、最愿意分享的那批。希望這篇分享能給你一點參考和力量在屬于你自己的工程師之路上走得更穩(wěn)、更遠。