大家好。
算起来，今年是我写前端代码的第八个年头了。
我刚入行的时候，是个纯粹的"技术宅"。我坚信一个道理：只要我把最新的框架玩得最熟，把最难的API研究得最透，把代码写得最漂亮，我的薪水就一定会水涨船高。
那时候，我热衷于在简历上写满各种时髦的技术名词，痴迷于用各种设计模式去重构一个简单的功能，并以此为傲。
直到我工作第五年的时候，一件事改变了我的看法。
当时我们组里有个同事，说实话，技术能力真的很一般。一个复杂点的组件，他可能要吭哧吭哧搞好几天。但他年底的绩效和晋升，都比我这个"技术骨干"要好。
我一开始很不服气。后来我才慢慢发现，他身上有一些我当时完全没在意，但却极其重要的能力。
干了八年，踩过无数的坑，我终于想明白一个道理：技术能力，决定了你的下限，让你不会被淘汰。但真正决定你薪资上限的，往往是那些技术之外的东西。
一、那些比"技术"更值钱的能力
当你的工作经验超过五年，大家在纯技术层面，其实很难拉开质的差距。你能写的业务，别人也能写。你会的Vue/React，别人也都会。这时候，想在团队里脱颖而出，拿到更高的薪水，你需要展现的是下面这几样能力。
1. 把技术语言，翻译成老板能听懂的"商业语言"
这是最重要，也最被技术人员忽略的能力。
我们常常这样向领导汇报工作：
"这周我重构了支付模块的代码，用了策略模式和依赖注入，代码的可维护性和扩展性大大提高了。"
你猜老板听完什么感觉？他可能一个字都没听懂，他只知道你这周好像没做任何新功能。
而那个比我先晋升的同事，他是这么说的：
"我这周优化了支付流程的代码。通过重构，我们把这个模块的平均bug率降低了30%，未来如果再接新的支付渠道，开发时间能从原来的5天缩短到2天。这次的投入，预计能为公司在下个季度节省大概50个工时的人力成本。 "
看到区别了吗？
老板不关心你用了什么设计模式，他只关心你做的事情，能为公司带来什么价值------是提升了效率，是降低了成本，还是减少了风险？
学会把你的技术工作，用"效率、成本、风险、收益"这些词包装起来，是让你"被看见"的第一步。
2. 向上管理 - 主动让你的价值被看见
很多技术人员，包括以前的我，都有一个误区：觉得只要我把活儿干好了，领导自然会看到，然后给我加薪。
这太天真了。"酒香也怕巷子深"，你的领导很忙，他要管很多人，很多事。你如果不主动说，他真的可能不知道你为了解决一个线上Bug，熬了几个通宵。
"向上管理"不是溜须拍马，而是主动、定期地通过专业的沟通，让你的上级了解你的工作进展、成果以及遇到的困难。
别等领导找你，你要主动约他。聊聊你最近的工作，你对项目的思考，你的成长和困惑。解决了一个难题，别只说"搞定了"。要把过程中的思考、你尝试过的失败方案、最终方案的好处，简明扼要地展现出来。
让领导知道你不仅能"做事"，还能"思考"，这很重要。
3. 让自己不只是一个"前端"
在一个项目里，如果你只会说"这是后端的问题，不归我管"或者"这是UI设计稿的问题"，那你的天花板就已经注定了。
一个能拿高薪的资深工程师，他一定是对整个产品链路都有思考的人。
- 懂一点后端：你能和后端工程师讨论API接口应该如何设计才更合理，而不是被动地接受。
- 懂一点UI/UX：你能给设计师提出建设性的意见，告诉他某个交互在技术上实现成本很高，但用另一种方式可以达到80%的效果，成本却只有20%。
- 懂一点业务：你得知道你做的这个功能，是给谁用的，解决了什么问题，在公司的商业版图里处于什么位置。
当你能跳出"前端"这个小圈子，站在产品、甚至公司的角度去思考问题时，你的价值就不再是一个"写代码的人"那么简单了。
4. 把事情"搞定"
最后，也是最关键的，是"搞定事情"。
一个项目，常常会因为各种原因卡住：需求不明确、后端接口延迟、测试资源不足......
初级工程师遇到这种情况，可能会两手一摊，开始"等待"。但资深工程师会主动出击。
- 需求不明确？他会主动拉上产品经理和设计，组织一个会议，把所有细节都敲定。
- 后端接口延迟？他会主动去找后端同学，了解困难，甚至一起看问题，或者自己用Mock工具先让前端流程跑起来。
一个人的薪水，本质上等于他能解决的问题的难度和重要性的总和。 而"推动跨部门的、模糊不清的事情最终落地"，就是一种非常重要的、能解决复杂问题的能力。
那技术还重要吗？
当然重要。
我说的这一切，都有一个绝对的前提：你必须有扎实过硬的技术能力。
技术是你的"1"，后面这些能力是"0"。没有了前面的"1"，后面有再多"0"也没有意义。技术过硬才是你的入场券，是你的底气。
我想表达的是，对于一个有8年经验的开发者来说，技术能力已经从"加分项"，变成了"基础项"。你不能再仅仅满足于此，你需要在这个"1"的后面，为自己加上更多的"0"。
所以，如果你感觉自己工作了好几年，技术水平好像也还不错，但薪水和职级却总也上不去，不妨可以停下来想一想。
你的问题，可能真的不在代码里，而在代码之外。
你是否能把你的工作，用对方能听懂的方式表达出来？
你是否让你的努力和价值，被正确的人看见了？
你是否愿意多走一步，去了解你工作之外的世界？
你是否能成为那个，在事情卡住时，大家都会信赖地把球传给你的人？
想清楚这些问题，可能比你多学一个新框架，更有价值。
你们觉得呢？