我大概是在工作的第五年,晋升到了高级前端工程师。那时候我挺自豪的,觉得自己技术不错,能独立负责复杂的业务,也能搞定线上疑难杂症,再往上走,应该也只是时间问题。
但没想到,高级这个title,我一挂就是三年多。
其中有整整两年,我感觉自己撞到了一堵看不见的墙。我明明是团队里解决技术难题最多的人,写的代码质量也公认是最好的,但每次晋升季,我和老板聊,得到的反馈总是有点虚:
“要多思考业务价值。”
“要展现出更大的影响力。”
“要多看看owner的角度。”
说实话,我当时听得一头雾水,甚至有点不服气。我想的是:“我一个工程师,不就是把技术搞好,把代码写漂亮吗?影响力?那不是Leader该考虑的事吗?”
这篇,就是想复盘一下我卡住的那两年,我是如何迷茫,又是如何最终想明白,从高级到资深(或者叫专家、Staff),真正需要跨越的到底是什么。
在被“卡住”的那两年里,我的状态可以用四个字来形容:战术勤奋。
我做了很多事,而且自认为做得很好:
我做了这么多,为什么还不够?我当时觉得很不公平。我把成为一个技术更强的人,当成了唯一的晋升路径,并且认为自己已经在这条路上走得够远了。
这就是我掉进去的第一个陷阱:把高级当成了个人能力的顶点,而没有去理解“资深”这个角色,到底需要什么不一样的能力。
真正的转变,来自一次和公司一位架构师的午餐。
我向他抱怨了我的困惑,他听完后,问了我一个问题:
“你觉得,是你自己一个人,一个月写1万行高质量的代码,对公司的价值大;还是你花一半的时间,让团队里其他5个人,每个人都能写出和你一样80%水平的代码,对公司的价值大?”
这个问题,像一道闪电一样击中了我。
我慢慢发现, 高级工程师的价值,体现在他能独立搞定复杂问题。而资深工程师的价值,体现在他能带领和影响一群人,去持续地搞定一系列复杂问题。
前者的产出,上限就是他自己一个人的时间和精力。而后者的产出,是可以被放大的。
我终于理解了老板口中的影响力是什么意思。我的价值,不再是我自己写了多少行牛逼的代码,而是因为我的存在,我们整个团队的代码质量、开发效率、技术氛围有没有得到系统性的提升。
我的工作重心,需要从关注事,转变为关注人;从关注个人产出,转变为关注团队产出。
想明白了这个道理后,我不再纠结于我明明干得最多,而是开始有意识地改变我的工作方式。
我不再满足于产品经理给我一个PRD然后我闷头做。在需求评审时,我会拉着他一起讨论:
这个需求的真实业务目标是什么?是为了提升用户留存,还是为了增加收入?
为了达到这个目标,目前的设计是最简单的方案吗?有没有更轻量的技术方案能达到80%的效果?
我开始把一部分精力,从如何实现,转移到了为何实现和如何更聪明地实现上。
遇到一个线上Bug,我不再只是把它修复就完事。我会花更多时间去思考:
我开始刻意减少自己写一线业务代码的时间,把更多的时间花在赋能上:
我开始主动去跟后端、跟测试、跟运维的同事聊天,了解他们的痛点,思考如何在前端层面,帮助他们解决问题。比如,和后端一起约定更合理的数据结构,或者开发一个Mock工具方便他们自测。我开始承担起一个技术方案指定角色。
当我开始做这些转变之后,大概又过了一年,我的晋升,就成了水到渠成的事。
现在回过头看,从高级到资深,要攀登的根本就不是同一架梯子。
那两年,我并没有白等。那段卡住的时期,虽然痛苦,但它逼着我去思考代码之外的东西。
如果你也正卡在这个阶段,希望我的这点思考,能给你一些启发。
最后,你们也有过这种焦虑吗?🙂
——转载自:ErpanOmer