我大概是在工作的第五年，晋升到了高级前端工程师。那时候我挺自豪的，觉得自己技术不错，能独立负责复杂的业务，也能搞定线上疑难杂症，再往上走，应该也只是时间问题。
但没想到，高级这个title，我一挂就是三年多。
其中有整整两年，我感觉自己撞到了一堵看不见的墙。我明明是团队里解决技术难题最多的人，写的代码质量也公认是最好的，但每次晋升季，我和老板聊，得到的反馈总是有点虚：
"要多思考业务价值。"
"要展现出更大的影响力。"
"要多看看owner的角度。"
说实话，我当时听得一头雾水，甚至有点不服气。我想的是："我一个工程师，不就是把技术搞好，把代码写漂亮吗？影响力？那不是Leader该考虑的事吗？"
这篇，就是想复盘一下我卡住的那两年，我是如何迷茫，又是如何最终想明白，从高级到资深（或者叫专家、Staff），真正需要跨越的到底是什么。
高级工程师的陷阱：以为自己技术无敌
在被"卡住"的那两年里，我的状态可以用四个字来形容：战术勤奋。
我做了很多事，而且自认为做得很好：
- 产品经理提的需求，无论多复杂，到我手里，我都能拆解得明明白白，然后用最优雅的代码实现出来，交付质量又高又快。
- 团队里有别人搞不定的Bug，最后基本都是我来收尾。我是大家公认的技术上的"定海神针"。
- 社区出了什么新技术，我总是第一个去研究，然后尝试在项目里引入，比如把打包工具从Webpack换到Vite。
我做了这么多，为什么还不够？我当时觉得很不公平。我把成为一个技术更强的人，当成了唯一的晋升路径，并且认为自己已经在这条路上走得够远了。
这就是我掉进去的第一个陷阱：把高级当成了个人能力的顶点，而没有去理解"资深"这个角色，到底需要什么不一样的能力。
从我到我们
真正的转变，来自一次和公司一位架构师的午餐。
我向他抱怨了我的困惑，他听完后，问了我一个问题：
"你觉得，是你自己一个人，一个月写1万行高质量的代码，对公司的价值大；还是你花一半的时间，让团队里其他5个人，每个人都能写出和你一样80%水平的代码，对公司的价值大？"
这个问题，像一道闪电一样击中了我。
我慢慢发现， 高级工程师的价值，体现在他能独立搞定复杂问题。而资深工程师的价值，体现在他能带领和影响一群人，去持续地搞定一系列复杂问题。
前者的产出，上限就是他自己一个人的时间和精力。而后者的产出，是可以被放大的。
我终于理解了老板口中的影响力是什么意思。我的价值，不再是我自己写了多少行牛逼的代码，而是因为我的存在，我们整个团队的代码质量、开发效率、技术氛围有没有得到系统性的提升。
我的工作重心，需要从关注事，转变为关注人；从关注个人产出，转变为关注团队产出。
为了破局，我开始做的几件事
想明白了这个道理后，我不再纠结于我明明干得最多，而是开始有意识地改变我的工作方式。
- 从接需求到反问需求
我不再满足于产品经理给我一个PRD然后我闷头做。在需求评审时，我会拉着他一起讨论：
-
这个需求的真实业务目标是什么？是为了提升用户留存，还是为了增加收入？
-
为了达到这个目标，目前的设计是最简单的方案吗？有没有更轻量的技术方案能达到80%的效果？
我开始把一部分精力，从如何实现，转移到了为何实现和如何更聪明地实现上。
- 从解决问题到预防问题
遇到一个线上Bug，我不再只是把它修复就完事。我会花更多时间去思考：
- 为什么会产生这个Bug？ 是不是我们的代码规范有问题？是不是缺少了某个Eslint规则？是不是某个公共组件的设计有缺陷？
- 然后，我会推动建立一个机制，去系统性地预防同类问题再次发生。比如，为核心逻辑补充单元测试、推动建立Code Review的Checklist、重构那个有缺陷的公共组件。
- 从个人输出到团队为重
我开始刻意减少自己写一线业务代码的时间，把更多的时间花在赋能上：
- 更用心地做Code Review：我提的建议，不再只是这里有个bug，而是"我们可以把这个逻辑抽成一个Hook，以后大家都能用"、"这个设计模式不错，我给你找篇文章可以深入了解下"。
- 主动做技术分享：我把最近研究的新技术、踩过的坑，整理出来在团队内部分享，帮助大家一起成长。
- 写文档：我开始为我们组的核心模块、复杂的业务流程写文档，极大地降低了新人的上手成本。
我开始主动去跟后端、跟测试、跟运维的同事聊天，了解他们的痛点，思考如何在前端层面，帮助他们解决问题。比如，和后端一起约定更合理的数据结构，或者开发一个Mock工具方便他们自测。我开始承担起一个技术方案指定角色。
当我开始做这些转变之后，大概又过了一年，我的晋升，就成了水到渠成的事。
现在回过头看，从高级到资深，要攀登的根本就不是同一架梯子。
那两年，我并没有白等。那段卡住的时期，虽然痛苦，但它逼着我去思考代码之外的东西。
如果你也正卡在这个阶段，希望我的这点思考，能给你一些启发。
最后，你们也有过这种焦虑吗？🙂