普通程序员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个新技术"这种表述。数量是安慰剂，深度才是复利。

你现在卡在哪一步？是还在收藏夹里淹着，还是已经能闻到自己三个月前的代码味了？