這幾年在組里看過不少同事準(zhǔn)備職稱材料,發(fā)現(xiàn)一個挺有意思的現(xiàn)象:有個做了七八年的老哥,線上故障排查能力特別強,每次救火都是他頂上去,但到評審的時候,他自己的材料寫得特別干,就幾行字——"負(fù)責(zé)某某系統(tǒng)優(yōu)化""解決了若干性能問題",評委看完根本不知道他到底做了什么。反倒是另一個做了五年的同事,技術(shù)深度可能還差點意思,但他每次項目結(jié)束都會整理一份文檔,把背景、難點、方案都寫清楚,評審時一翻材料就能看出他干了哪些事。結(jié)果你猜怎么著,后者先過了。

這事讓我想明白一件事:工程師光把活干漂亮還不夠,你得讓別人看見你干了什么,更重要的是,讓別人理解你做這件事的價值在哪。這不是什么虛的東西,就是實打?qū)嵉穆殘錾婕寄堋?/p>

先說技術(shù)積累這塊。很多人覺得我天天寫代碼、改Bug、上線發(fā)版,這些就是積累了。但你仔細(xì)想,三五年經(jīng)驗和七八年經(jīng)驗的工程師,差別到底在哪?不只是代碼量的區(qū)別,更多是你在項目里承擔(dān)的角色不一樣了。做了三五年,你可能還在具體模塊里深挖,比如把某個接口的響應(yīng)時間從兩百毫秒優(yōu)化到五十毫秒,或者重構(gòu)了一段屎山代碼讓后續(xù)維護變簡單。這些都很扎實,但評審時你要能說清楚:為什么要做這個優(yōu)化?影響了多少用戶?節(jié)省了多少資源?到了五年往上,你應(yīng)該開始帶一些小模塊,或者在跨團隊的技術(shù)方案里有自己的判斷,比如在某次架構(gòu)討論會上,你提出的方案被采納了,最后幫整個系統(tǒng)規(guī)避了一次潛在的容量瓶頸。這種事情不記下來,過半年你自己都忘了。

我的建議很簡單:每次項目結(jié)項或者季度復(fù)盤的時候,花半小時把自己做的三件最關(guān)鍵的事記下來。不用寫得多fancy,就按"什么時間、碰到什么問題、我做了什么、結(jié)果怎么樣"這個結(jié)構(gòu)來。比如去年雙十一之前,你發(fā)現(xiàn)某個服務(wù)在壓測時CPU飆高,你排查出是某個地方有熱點數(shù)據(jù)沒做緩存,加了緩存之后CPU使用率降了百分之四十,這次大促期間沒出過問題。就這么幾句話,但信息都在了。平時攢著,到評審前一翻,你會發(fā)現(xiàn)自己其實做了不少事,只是當(dāng)時沒意識到要留痕。

再說材料怎么寫。很多工程師寫東西特別惜字如金,或者反過來,寫了一大堆技術(shù)細(xì)節(jié),但看的人云里霧里。你得記住,評審的人不一定懂你那個領(lǐng)域的所有細(xì)節(jié),你要用他們能聽懂的方式講清楚。舉個例子,有人會寫"優(yōu)化了數(shù)據(jù)庫查詢",這就太空了。你可以改成"某個報表頁面加載要十幾秒,用戶投訴特別多,我排查發(fā)現(xiàn)是查詢時沒走索引,加了索引之后頁面打開時間降到兩秒以內(nèi),投訴量下降了百分之八十"。前后對比一下,后者讓人一眼就能看出你解決了一個真實的用戶痛點,而不是為了優(yōu)化而優(yōu)化。

還有一點,工程師容易陷入的誤區(qū)是覺得"我就是個寫代碼的,不需要搞什么人際關(guān)系"。但實際上,評審看的不只是你一個人悶頭干活的能力,還要看你能不能跟別人配合,能不能把你的經(jīng)驗傳遞出去。這不是讓你去搞辦公室政治,而是說你在日常工作里,是不是愿意幫其他組解決問題,是不是帶過新人,是不是在團隊分享會上講過你踩過的坑。這些事情做多了,到評審的時候,組里的人、合作過的其他團隊,都會記得你。我見過一個做基礎(chǔ)架構(gòu)的同事,他每次解決完一個棘手問題,都會寫個簡短的復(fù)盤文檔發(fā)在內(nèi)部群里,時間長了大家有類似問題都會來找他。后來他申報高級工程師,好幾個組的人都幫他說話,這種影響力是平時一點一點積累出來的。

說到底,技術(shù)和溝通從來不是對立的。你把技術(shù)做扎實,然后學(xué)會用別人聽得懂的方式講出來,讓你的價值被看見,這才是一個完整的職業(yè)發(fā)展路徑。評審只是一個節(jié)點,真正有用的是你在這個過程里養(yǎng)成的習(xí)慣:做事留痕、總結(jié)復(fù)盤、主動分享。這些東西不僅幫你過評審,更會讓你在后面的職業(yè)生涯里走得更順。