最优秀的一批程序员，在用最蠢的方式写代码
善战者，无赫赫之功。
这句话的字面意思是说，总是轻松打胜仗的将军，别人就会觉得他没有多少功劳。
那对于一个程序员来说，按部就班的完成需求，算不算一种成绩？
悲观地说，可能并不算。
不出bug的程序员是好程序员吗？
前不久，有个大厂离职员工发了个帖子。
他说，自己写代码战战兢兢，充分测试，联调顺利，所以也很少加班，也没有多少问题单需要处理。
可这样做的后果就是在公司根本没有存在感，考评的时候，高绩效反而给了那些天天加班处理问题的。
他所在的公司，考评体系是将代码量和绩效挂钩的，所以周围的程序员都把代码写得臃肿无比、难以维护。
而这个程序员自己，则因为无法适应这种文化，被处处排挤，最终离职。
这就是个很典型的“善战者无赫赫之功”的例子。
为了避免过于平庸，在这个团队中，可能有非常多的程序员都在有意无意的用这种蠢方式写代码。
因为只有通过这种看起来很蠢的方式，他们才能实现：
-
提高本人对于项目组的重要性，因为现在只有他本人看得懂这套代码，别人一动就会出bug
-
给领导留下一个奋斗者形象，天天加班写代码、改bug，感觉全项目组的问题都是他在处理
这太不合理了，事情为什么会变成这样？
问题的关键在于考核。
该如何考核程序员？
不同于其他岗位，如市场岗位可以根据销售额去定绩效，产品岗位可以根据关键指标去评判，但技术岗好像用什么维度都不太完美。
用工作量考核？
上文就是个典型的例子，如果一个程序员能轻松处理每一个任务，短短几行代码就能完成一个超级复杂的需求，每天到点下班，那么在老板看来，他很有可能是工作不饱和。
相反，那些代码臃肿，每天加班改bug的程序员，虽然技术水平欠佳，但老板却很满意。
技术水平高，和技术水平看起来高，是两码事，所以单纯用代码量考核，并不合理。
那，用业务效果评判？
一般来说，程序员只负责处理产品经理提出的需求。
而业务方向、实现形式都是产品经理决定的，而程序员能做的就是保质保量地还原方案，保障稳定性，好像和“业务效果”也没有太多关系？
用人工评判呢？
各大公司派系林立，管理者任人唯亲的不在少数，办公室政治也普遍存在。
程序员很多是醉心于技术，不善于表达的类型，也许能力很强，但人缘却处理不好，在人工评判中就非常劣势，反而是一些善于搞关系、强于汇报的人能够上位。
缺乏一个合理的考核标准，就不能准确界定每个程序员的贡献。
这也是很多优秀的程序员迟迟难以晋升的原因。
程序员要如何突出自己的价值？
在脉脉上，一个人分享了他是如何将一个老前端问得哑口无言的。
其实，这个老前端被问住，不是因为他本身的问题，更多是岗位本身的属性如此。
程序员一般不参与业务决策，仅仅是完成需求，也不需要额外做什么。
长此以往，做汇报的时候就很吃亏。
而且还原需求这件事，你能做，别人也能做，甚至一些基础的任务，一个刚毕业的大学生经过培训都能做。
在业务普遍增长，招聘需求遍地的时期，这类程序员还算稳定。
但在招聘需求越来越收窄，各大业务线都在裁员缩招的当下，突出个人价值这件事，就突然变得非常紧要了！
我足够优秀吗？
我是否比身边的人更强？
如果裁员真的发生，我是被保留的，还是被淘汰的？
这些问题，都要重新去考虑。
上面说到，技术水平高，和技术水平看起来高，是两码事。
那技术水平高的人，如何让自己的技术水平同样“看起来高”呢？
肯定不至于用上面说的“蠢办法”去写代码，因为这是病态的。
我的建议是，从现在开始，有意识的进行“自我增值”。
这个增值，指的是在完成本质工作之余，主动优化流程，充分迭代，也可以是造更好的轮子，引入新架构等等。
例如，对需求进行分析后，不是简单利用模板，而是引入一套效率更高，功能更强的框架，来提升功能的体验。
或者，通过借鉴一些业内的优秀案例，对现有项目的架构进行优化。
这样，既能给业务带来增长，也能充实自己的履历。
你个人的地位，在公司也会更加牢固。
当然，有人会说，公司的业务已经非常稳定了，可创新的角度有限，陈年老架构也没有优化的空间，这种时候又该怎么办呢？
这种时候，我们要从两个角度去看——
业务真的是没有优化空间，还是以你现在的水平，压根没法做到在这个基础上进行优化？
如果是前者，那么恭喜你，你所处的项目已经非常成功，这本身就是你履历上值得大书特书的闪光点！
如果是后者，那么可能先提升自我的技术水平，是当前最需要做的事。
不论是用何种方式，在当下这个大环境下，去思考如何更好的为“自我增值”，是每个程序员都无法逃避的话题。
寒冬已至，我们每个人都要思考如何活下来。