普通程序員8年爬坑：從寫爛代碼到帶團隊，第3步差點把我埋了

我見過太多人簡歷上寫著"精通"，面試時連Git分支都理不清。作者開篇就承認自己"ordinary"，這種坦誠反而讓我停下了劃走的手指。

他讀了無數大牛的文章，最后發現最管用的成長路徑，是從承認自己普通開始的。這不是謙虛，是省下了大量假裝懂的時間。

第一步：先跪再學

作者把祈禱放在技能樹的第一位。不管你信什么，這個邏輯很產品——先承認有東西在你控制之外，才能騰出腦子裝真東西。

我見過兩種新人：一種進來就說"這個我學過"，另一種說"這個我沒碰過，從哪開始"。三年后，后者的代碼庫通常干凈得多。前者的"學過"往往是看過半本教程。

作者提到的" oceans of information and still remain ignorant"（信息海洋里淹死的無知者），我翻譯一下：收藏夾里500篇沒看的文章，不等于你懂了。

第二步：找到你的"活地圖"

作者沒細說第二步，但提到了"seeking guidance"。我補一個觀察：好的mentor（導師）不是給你答案的人，是問你"你試過什么"的人。

有個朋友帶新人，對方問"這個bug怎么修"，他回"你斷點打在哪了"。新人愣住，因為根本沒打。三分鐘后自己找到了。這種mentor貴，但值。

作者強調"local and international"都讀，意思是別只盯著中文社區，也別迷信硅谷。GitHub上印度程序員的issue回復，有時候比官方文檔還清楚。

第三步：代碼能跑之后，立刻回頭聞味

這是作者差點翻車的地方，也是我想展開說的。

很多程序員卡在"能跑就行"。作者早期也這樣，直到他發現自己寫的模塊，別人接手要罵三天。不是功能錯，是命名像密碼、嵌套像迷宮、注釋像外星文。

他后來養成一個習慣：代碼合并前，自己先讀一遍，假裝是六個月后的自己。

這個"假裝"很難。我試過在注釋里寫"這里為什么這么寫"，三個月后再看，經常想抽當時的自己。但抽過幾次，寫的時候手就緊了。

作者沒說的細節是：他具體怎么重構的？我猜是從小處開始——把一個200行的函數拆成三個有名字的，比學設計模式見效快。

第四步到第六步：從"我會用"到"我懂為什么"

作者跳過了中間幾步的詳細描述，但給了一個線索：他不再滿足于實現功能，開始追問"這個框架為什么這樣設計"。

這是分水嶺。會用React（一種前端框架）和懂React的調度機制，面試時可能都答對題，但遇到性能瓶頸時，后者能聞到味道不對。

我見過的典型陷阱是：追新技術追成集郵。作者顯然避開了這個坑，因為他提到"quiet sense of satisfaction"——安靜滿足，不是朋友圈曬證書那種。

他的學習材料從教程變成了源碼。不是從頭到尾讀，是帶著問題讀。比如"這個報錯從哪拋出來的"，然后跟進去。這種讀法累，但一遍頂十遍。

第七步：讓別人用你的代碼不罵娘

作者開始寫文檔了。不是那種"安裝、運行、完畢"的三行說明，是解釋決策的文檔：為什么選方案A而不是B，哪個部分以后可能變。

這步的隱藏成本是：你得先承認自己可能錯。寫"這里可能有問題"比寫"完美實現"需要更多安全感。

有個細節作者沒提但我猜有：他開始review別人的代碼了。教是最好的學，尤其是教的時候發現自己也犯過同樣的錯。

第八步：從"解決問題"到"定義問題"

最后一步，作者的目標變了。不再是"這個需求怎么實現"，是"這個需求該不該做"。

這需要業務上下文。作者沒說他怎么拿到的，但通常路徑是：主動問產品經理"這個指標為什么重要"，然后自己跑數據驗證。

purpose-driven（目標驅動）這個詞，作者放在標題里，但正文解釋得很克制：就是知道自己寫的代碼最終幫誰省了時間、賺了錢、或者少生一次氣。

不是每個功能都值得驕傲。作者說"quiet sense of satisfaction"，我注意到quiet這個詞——這種滿足不需要別人點贊。

他最后留下的問題是：那些"hidden mistakes that stall careers"（拖垮職業生涯的隱藏錯誤），具體是什么？作者只暗示了第三步的重構拖延，其他的留給讀者自己對號入座。

我想到一個：把"忙"當成"充實"。作者八年路徑里，沒有一年是"學了20個新技術"這種表述。數量是安慰劑，深度才是復利。

你現在卡在哪一步？是還在收藏夾里淹著，還是已經能聞到自己三個月前的代碼味了？