最优秀的一批程序员，在用最蠢的方式写代码

善战者，无赫赫之功。

这句话的字面意思是说，总是轻松打胜仗的将军，别人就会觉得他没有多少功劳。

那对于一个程序员来说，按部就班的完成需求，算不算一种成绩？

悲观地说，可能并不算。

不出bug的程序员是好程序员吗？

前不久，有个大厂离职员工发了个帖子。

他说，自己写代码战战兢兢，充分测试，联调顺利，所以也很少加班，也没有多少问题单需要处理。

可这样做的后果就是在公司根本没有存在感，考评的时候，高绩效反而给了那些天天加班处理问题的。

他所在的公司，考评体系是将代码量和绩效挂钩的，所以周围的程序员都把代码写得臃肿无比、难以维护。

而这个程序员自己，则因为无法适应这种文化，被处处排挤，最终离职。

这就是个很典型的“善战者无赫赫之功”的例子。

为了避免过于平庸，在这个团队中，可能有非常多的程序员都在有意无意的用这种蠢方式写代码。

因为只有通过这种看起来很蠢的方式，他们才能实现：

1. 提高本人对于项目组的重要性，因为现在只有他本人看得懂这套代码，别人一动就会出bug
2. 给领导留下一个奋斗者形象，天天加班写代码、改bug，感觉全项目组的问题都是他在处理

这太不合理了，事情为什么会变成这样？

问题的关键在于考核。

该如何考核程序员？

不同于其他岗位，如市场岗位可以根据销售额去定绩效，产品岗位可以根据关键指标去评判，但技术岗好像用什么维度都不太完美。

用工作量考核？

上文就是个典型的例子，如果一个程序员能轻松处理每一个任务，短短几行代码就能完成一个超级复杂的需求，每天到点下班，那么在老板看来，他很有可能是工作不饱和。

相反，那些代码臃肿，每天加班改bug的程序员，虽然技术水平欠佳，但老板却很满意。

技术水平高，和技术水平看起来高，是两码事，所以单纯用代码量考核，并不合理。

那，用业务效果评判？

一般来说，程序员只负责处理产品经理提出的需求。

而业务方向、实现形式都是产品经理决定的，而程序员能做的就是保质保量地还原方案，保障稳定性，好像和“业务效果”也没有太多关系？

用人工评判呢？

各大公司派系林立，管理者任人唯亲的不在少数，办公室政治也普遍存在。

程序员很多是醉心于技术，不善于表达的类型，也许能力很强，但人缘却处理不好，在人工评判中就非常劣势，反而是一些善于搞关系、强于汇报的人能够上位。

缺乏一个合理的考核标准，就不能准确界定每个程序员的贡献。

这也是很多优秀的程序员迟迟难以晋升的原因。

程序员要如何突出自己的价值？

在脉脉上，一个人分享了他是如何将一个老前端问得哑口无言的。

其实，这个老前端被问住，不是因为他本身的问题，更多是岗位本身的属性如此。

程序员一般不参与业务决策，仅仅是完成需求，也不需要额外做什么。

长此以往，做汇报的时候就很吃亏。

而且还原需求这件事，你能做，别人也能做，甚至一些基础的任务，一个刚毕业的大学生经过培训都能做。

在业务普遍增长，招聘需求遍地的时期，这类程序员还算稳定。

但在招聘需求越来越收窄，各大业务线都在裁员缩招的当下，突出个人价值这件事，就突然变得非常紧要了！

我足够优秀吗？

我是否比身边的人更强？

如果裁员真的发生，我是被保留的，还是被淘汰的？

这些问题，都要重新去考虑。

上面说到，技术水平高，和技术水平看起来高，是两码事。

那技术水平高的人，如何让自己的技术水平同样“看起来高”呢？

肯定不至于用上面说的“蠢办法”去写代码，因为这是病态的。

我的建议是，从现在开始，有意识的进行“自我增值”。

这个增值，指的是在完成本质工作之余，主动优化流程，充分迭代，也可以是造更好的轮子，引入新架构等等。

例如，对需求进行分析后，不是简单利用模板，而是引入一套效率更高，功能更强的框架，来提升功能的体验。

或者，通过借鉴一些业内的优秀案例，对现有项目的架构进行优化。

这样，既能给业务带来增长，也能充实自己的履历。

你个人的地位，在公司也会更加牢固。

当然，有人会说，公司的业务已经非常稳定了，可创新的角度有限，陈年老架构也没有优化的空间，这种时候又该怎么办呢？

这种时候，我们要从两个角度去看——

业务真的是没有优化空间，还是以你现在的水平，压根没法做到在这个基础上进行优化？

如果是前者，那么恭喜你，你所处的项目已经非常成功，这本身就是你履历上值得大书特书的闪光点！

如果是后者，那么可能先提升自我的技术水平，是当前最需要做的事。​

不论是用何种方式，在当下这个大环境下，去思考如何更好的为“自我增值”，是每个程序员都无法逃避的话题。

寒冬已至，我们每个人都要思考如何活下来。