业务型程序员正在承受偏见

大公司似乎有个通病，就是没有给做业务的技术人员安全感以及应有的回报。似乎做技术、做基础建设的就要比做业务的更有价值。前者能为团队提效，能向外输出能力，这当然能作为绩效和晋升的评判标准。但为何一个能理解业务需求，按时交付代码，迅速拉通业务上下游的业务型程序员，也被要求做出「技术影响力」才可以晋升？

当然，优秀的程序员两者都应该有，但总得有一个侧重点，因为人的时间是有限的。而这种畸形的评判标准，会让做业务的程序员产生严重的焦虑 —— 我光做业务时间已经不够了，我哪有时间还去做基础建设呢？

不光如此，它还会造成另一种副作用，就是做业务的程序员，在想方设法地去造轮子，创造伪需求。明明用原生的 API 就能搞定的事，非要「封装」一下，除了制造一种「高级感」，一无是处，有时听到这些方案都会觉得尴尬。

我不是反对造轮子，我是反对造不应该造的轮子。这样的轮子造出来了，PPT 写好了，做的人晋升了，维不维护，那是之后再说吧。苦的还是用它来做业务的队友们。

真正的基础建设，是让使用者觉得好用，方便，靠谱，解决了真正的痛点，让业务跑得更快，更稳，用了这种技术，原本要写两天的程序，现在两小时能完成。这些有意义的基础建设，不是在办公室开两小时会就能想出来的，是业务刚好遇到对应的场景才做得出来的。但是，谁都不愿意承认这个事实，因为你不搞技术，你就没有所谓的技术影响力，你就晋升不了了。

我能理解那些瞎造轮子的人是制度使然。游戏规则就是这样，你想玩得好，无论规则多傻逼，都要按照规则去玩。

有人说，你就做业务，太容易被取代了。我想说，做业务，也有分做得好不好的，你做什么事情可以做不好还不被取代？除非有一种编程语言只有你会。还有人说，未来 AI 都能写代码了。我只知道，现在我连一个靠谱的能帮我糊 HTML 页面的 AI 我都没见到，50 年内，可以出现一个能理解产品经理的需求，自动写出符合需求的代码的 AI ?

所以，技术人员的晋升标准应该改为有两个不同的方向 —— 业务型人员和技术型人员。两者都应该有不同的评判标准，两个不同的晋升体系。让做业务的人专于完成业务，让做技术的人专心服务业务。没有谁比谁的价值低。

（利益相关：我这三年做的几乎都是基建）

mcfog

2019-07-24 10:21:46 +08:00

我反而觉得做业务安全感比做基建高多了，做基建不写业务，一旦晋升受挫，跳槽范围就锁定大公司，小公司根本没这个预算。做业务一个不行换一个，一家公司不行换一家公司

怎么应对大公司瞎造轮子浪费资源的现象那是大公司 CTO 的课题你我都不到这个层面，不如说如果并没有花力气解决，说明这种浪费并不是大公司现在面临的最大的问题，倒是技术人员的晋升评级体系一直是个问题