这是一个创建于 2273 天前的主题，其中的信息可能已经有所发展或是发生改变。
大公司似乎有个通病，就是没有给做业务的技术人员安全感以及应有的回报。似乎做技术、做基础建设的就要比做业务的更有价值。前者能为团队提效，能向外输出能力，这当然能作为绩效和晋升的评判标准。但为何一个能理解业务需求，按时交付代码，迅速拉通业务上下游的业务型程序员，也被要求做出「技术影响力」才可以晋升？
当然，优秀的程序员两者都应该有，但总得有一个侧重点，因为人的时间是有限的。而这种畸形的评判标准，会让做业务的程序员产生严重的焦虑 我光做业务时间已经不够了，我哪有时间还去做基础建设呢？
不光如此，它还会造成另一种副作用，就是做业务的程序员，在想方设法地去造轮子，创造伪需求。明明用原生的 API 就能搞定的事，非要「封装」一下，除了制造一种「高级感」，一无是处，有时听到这些方案都会觉得尴尬。
我不是反对造轮子，我是反对造不应该造的轮子。这样的轮子造出来了，PPT 写好了，做的人晋升了，维不维护，那是之后再说吧。苦的还是用它来做业务的队友们。
真正的基础建设，是让使用者觉得好用，方便，靠谱，解决了真正的痛点，让业务跑得更快，更稳，用了这种技术，原本要写两天的程序，现在两小时能完成。这些有意义的基础建设，不是在办公室开两小时会就能想出来的，是业务刚好遇到对应的场景才做得出来的。但是，谁都不愿意承认这个事实，因为你不搞技术，你就没有所谓的技术影响力，你就晋升不了了。
我能理解那些瞎造轮子的人是制度使然。游戏规则就是这样，你想玩得好，无论规则多傻逼，都要按照规则去玩。
有人说，你就做业务，太容易被取代了。我想说，做业务，也有分做得好不好的，你做什么事情可以做不好还不被取代？除非有一种编程语言只有你会。还有人说，未来 AI 都能写代码了。我只知道，现在我连一个靠谱的能帮我糊 HTML 页面的 AI 我都没见到，50 年内，可以出现一个能理解产品经理的需求，自动写出符合需求的代码的 AI ?
所以，技术人员的晋升标准应该改为有两个不同的方向 业务型人员和技术型人员。两者都应该有不同的评判标准，两个不同的晋升体系。让做业务的人专于完成业务，让做技术的人专心服务业务。没有谁比谁的价值低。
（利益相关：我这三年做的几乎都是基建）
当然，优秀的程序员两者都应该有，但总得有一个侧重点，因为人的时间是有限的。而这种畸形的评判标准，会让做业务的程序员产生严重的焦虑 我光做业务时间已经不够了，我哪有时间还去做基础建设呢？
不光如此，它还会造成另一种副作用，就是做业务的程序员，在想方设法地去造轮子，创造伪需求。明明用原生的 API 就能搞定的事，非要「封装」一下，除了制造一种「高级感」，一无是处，有时听到这些方案都会觉得尴尬。
我不是反对造轮子，我是反对造不应该造的轮子。这样的轮子造出来了，PPT 写好了，做的人晋升了，维不维护，那是之后再说吧。苦的还是用它来做业务的队友们。
真正的基础建设，是让使用者觉得好用，方便，靠谱，解决了真正的痛点，让业务跑得更快，更稳，用了这种技术，原本要写两天的程序，现在两小时能完成。这些有意义的基础建设，不是在办公室开两小时会就能想出来的，是业务刚好遇到对应的场景才做得出来的。但是，谁都不愿意承认这个事实，因为你不搞技术，你就没有所谓的技术影响力，你就晋升不了了。
我能理解那些瞎造轮子的人是制度使然。游戏规则就是这样，你想玩得好，无论规则多傻逼，都要按照规则去玩。
有人说，你就做业务，太容易被取代了。我想说，做业务，也有分做得好不好的，你做什么事情可以做不好还不被取代？除非有一种编程语言只有你会。还有人说，未来 AI 都能写代码了。我只知道，现在我连一个靠谱的能帮我糊 HTML 页面的 AI 我都没见到，50 年内，可以出现一个能理解产品经理的需求，自动写出符合需求的代码的 AI ?
所以，技术人员的晋升标准应该改为有两个不同的方向 业务型人员和技术型人员。两者都应该有不同的评判标准，两个不同的晋升体系。让做业务的人专于完成业务，让做技术的人专心服务业务。没有谁比谁的价值低。
（利益相关：我这三年做的几乎都是基建）
 | 1 xiaoyazi 2019-07-24 09:55:41 +08:00 via iPhone  17 在 v 站算质量高的帖子了 |
 | 2 jk1030 2019-07-24 09:57:24 +08:00 所以现在有业务架构呵业务专家的说法 但是实际看起来并不友好 |
 | 3 xcold 2019-07-24 10:00:28 +08:00 这一年都是救火队员 |
 | 4 VoidChen 2019-07-24 10:00:54 +08:00 1 可能主要是“没有技术壁垒就会被轻易取代”这种观念带来持续性变化吧，军师以一当千，但打仗还是要将士去填 |
 | 5 vmskipper 2019-07-24 10:15:10 +08:00 1 客服程序员 闲的一笔 岁数大了 有点焦虑 很多公司都没有对应的坑。。。。 |
 | 6 happinessnch 2019-07-24 10:15:35 +08:00 “没有谁比谁的价值低” 对于一家商业公司来说，每一个职务都有着不同的价值，取决于不可替代性、影响力等等因素，美其名曰企业文化。 所以，就一定会也必须要出现个体价值的差异，个人价值不好体现，是每一个公司都要面临的问题，但是将资源放到更有效的地方，是资本的宿命，而价值就是资本的引导棒。 |
 | 7 zeybar 2019-07-24 10:16:10 +08:00 游戏规则如此，想要生存就得拼命学 |
 | 8 doublleft 2019-07-24 10:16:33 +08:00 3 不用急，专心积累产品经验，用不了几年就会创业，然后招技术型程序员进来。 |
 | 9 xiongshengyao 2019-07-24 10:17:25 +08:00 我觉得光是理解产品经理的需求这一点就很难了 |
 | 10 zindex 2019-07-24 10:18:15 +08:00 1 和你相反，我这边对晋升的要求是对业务的理解，一切都是业务优先，技术上的产出也是要从业务需求出发，不然老板是不会认的。业务做不好真的完全没有安全感。一个业务做的好的同学基本就是绩效最好的。（在你隔壁部门，所以这个事情还是看老板的，不是整个公司这样） |
 | 11 o0 2019-07-24 10:19:35 +08:00 大家都在出各种能够提高门槛的新技术，学不动了，天呐。 |
 | 12 royeyu 2019-07-24 10:19:47 +08:00 3 摸鱼型程序员表示不服 |
 | 13 mcfog 2019-07-24 10:21:46 +08:00 via Android 我反而觉得做业务安全感比做基建高多了，做基建不写业务，一旦晋升受挫，跳槽范围就锁定大公司，小公司根本没这个预算。做业务一个不行换一个，一家公司不行换一家公司 怎么应对大公司瞎造轮子浪费资源的现象那是大公司 CTO 的课题你我都不到这个层面，不如说如果并没有花力气解决，说明这种浪费并不是大公司现在面临的最大的问题，倒是技术人员的晋升评级体系一直是个问题 |
 | 14 ben1024 2019-07-24 10:22:32 +08:00 大小公司都有，社会风气加上工作的本质 |
 | 15 acidsweet 2019-07-24 10:24:23 +08:00 1 感觉写的是我大福报厂啊 |
 | 16 1044523901 2019-07-24 10:24:34 +08:00 游戏规则 |
 | 17 mrgeneral 2019-07-24 10:24:40 +08:00 哪个公司敢说自己是技术驱动的？没有业务公司怎么活下去？ 你造的轮子业务不用你的产出就是 0，KPI 就是 0，吹出花来也没用啊，没有收益。 “业务型人员和技术型人员。两者都应该有不同的评判标准，两个不同的晋升体系。” 这个我认同，毕竟面对的方向不一样 |
 | 18 happyrider 2019-07-24 10:29:11 +08:00 你说的是有道理的。 最好的管理应该是专注于评价一个人有没有把他岗位的职责实现最好！是结果最好，永远不是过程最好。 我们国家不重视管理，没有系统的管理意识。 |
 | 19 leisure 2019-07-24 10:29:25 +08:00 很多小厂现在也是这种大厂病啊... |
 | 20 aniskin 2019-07-24 10:30:25 +08:00 5 分阶段的 刚工作的跳槽频率比较高的时候技术比较重要，除非是跳槽到同行业的公司，否则前公司的业务积累没有任何用处 但是如果是中高级以上的技术岗位，业务沉淀就能加分了 |
 | 21 justfly 2019-07-24 10:32:19 +08:00 技术型程序员正在走向自闭，怀念很久以前有产品交流，有人投食的日子。 |
 | 22 luoway 2019-07-24 10:35:42 +08:00 1 利益相关：我做的 1 年基建，2 年业务 感觉做业务更安全，基建会焦虑、加班。 做业务的同学往往有产品、项目经理带着，有着明确的方向， 做基建的同学，特别是低职级的，往往没有明确的方向，做的东西一般是整个基建中重复程度最高，技术含量最低的部分，想上升就得多学，这也是基建低职级同学的优势：更多的学习压力、动力。 而高职级的，据我所见，要么很闲（没有目标，收集痛点阶段），要么加班（找到目标，解决问题阶段），计划性、作息规律都不如业务同学。 |
 | 23 mars0prince 2019-07-24 10:38:50 +08:00 兄弟，你还没理解，做业务是你本职工作，你业务做得不好，线上出问题，就不是晋升不了，而是直接就打 C 开除了。而技术建设是你的 bonus。 |
 | 24 Tomorrowxxy 2019-07-24 10:39:34 +08:00 我是放火队员 |
 | 25 zxcslove 2019-07-24 10:41:34 +08:00 分析的是很到位了，这锅肯定是大领导来背。任何成员和资源都应是为核心目标效力的，反馈机制自然要紧贴战略来设计。 |
 | 27 sgissb1 2019-07-24 10:44:24 +08:00 2 也不能完全说是业务型程序员正在受偏见。应该说是从中国 IT 产业嫌弃开始，业务程序员的位置就被人放的比较低。也仅仅是近几年，业务程序员的地位才逐渐凸显。最简单的例子就是“互联网”企业的爆发，导致这些企业更多注重业务的实现到各种修饰（包装）。 技术型程序员和业务型程序员之间我的理解是没有严格的区分，因为一个好的程序员在技术发展路线上有偏好是正常的，但是过分偏科就很有些不太合适了。 毕竟程序员只是一种技术操作工，并不是搞科研，搞科研的可以潜心做精一件事。而对于操作工来说知识面也应该略有拓展。 所谓的技术型程序员和业务型程序员之间的“矛盾”，主要还是来自内心的浮躁，比如互相看不起，互相各种指手画脚（不尊重）。 就拿技术型程序员内部来说，都还有很强的所谓鄙视链。人和人之间各种浮躁，浮夸，鄙视链也是比较比较传统的事情。见惯不怪了。 ps: 所谓的技术型程序员 |
 | 28 rb6221 2019-07-24 10:50:26 +08:00 via iPhone 1 传统 it 行业，业务型程序员的重要性是很高的。比如金融银行，车企，航空公司，招聘要求几乎都需要你熟悉业务，重要性比技术更重要。 但是，业务型有个致命问题，那就是业务型程序员无法创造和推动。他们只是把需求理解，做出来。而技术型，会在本身系统已经跑的挺好的情况下，思考怎样“更好”。其实这就是所谓的“锦上添花”吧。 业务型程序员，没有评判标准，那是因为，无论你理解的如何，最终成品的标准都是不变的，。一个业务生疏的，硬着头皮也要做出来，一个业务熟悉的，轻松就可以做出来，那出来以后，谁能看出哪个人更好？ |
 | 29 lowman 2019-07-24 10:51:49 +08:00 6 I am crud man, 享受着查询数据库所带来的一阵, 一阵, 一阵阵的快感 |
 | 30 sxshi110 2019-07-24 10:53:11 +08:00 说的很棒，深有感触。 在小公司摸爬滚打了几年业务了，对这行的业务基本上能做到信手拈来，也基本上到了业务程序员暂时能到的瓶颈了，想继续升，真有点迷茫。继续做业务型的，去其他公司基本上就是平移，涨幅升迁不大，也都是类似的小公司；想做点基建，做业务的都应该能理解，时间上真的不宽裕。不过还是希望自己能掌握更多吧，这样才能有升值价值。 |
 | 31 ieiayaobb 2019-07-24 10:57:04 +08:00 业务型程序员在跳槽市场是没有竞争力的，你跟新雇主说你如何精通原有的领域，除非你们在同一个行业，否则新雇主永远觉得你经历的业务不如他的业务复杂，你的业务知识也对其没有任何帮助，这是必然。 所以你才会看到很多业务型程序员拼命的往基础开发、框架开发上爬，因为这些才是放之四海而皆准的东西。 另一方面，纯技术型开发对企业带来的价值是长远的，或者是没那么显而易见的。框架本身就是为了提高业务型程序员的工作效率而存在的，但提高效率这事并没有那么好评价。 羡慕楼主在做基础建设还能受上层重视，我们曾经的平台（或者现在主流叫的中台）团队，基本在老板看来是烧钱不产出的团队，ROI 几乎为零，以至于部门负责人一直在想办法帮这种技术团队兑现价值，非常可笑。 |
 | 32 hyy1995 2019-07-24 10:59:04 +08:00 大部分人平时工作写的都是业务逻辑。。。 |
 | 33 cyril4free 2019-07-24 11:02:45 +08:00 取决于公司吧，比如某个业务为导向的公司，业务线上投入比基础多多了，以至于业务线上人多到自己搞基础设施 |
 | 34 Gathaly 2019-07-24 11:02:54 +08:00 恕我直言，所谓的框架和业务逻辑都是为了业务盈利服务 不如硬件协议栈、算法统筹类基建 |
 | 35 momocraft 2019-07-24 11:08:49 +08:00 真能造出好用的轮子当然好，做到大可能就是 SAP 那样 如果简单封装就能有正反馈，可能评价体系有问题 |
 | 36 iyaozhen 2019-07-24 11:09:13 +08:00 via Android 我们晋升是两条线，你说的这两种。 但是要看情况，也有可能业务型的更好写 PPT，你做了一个非常好的功能，老板看得见摸得着。 基础类的有时容易被挑战，因为我们晋升偏技术评审，拿开源的不一定能忽悠过去，而且公司很大很容易和别人撞轮子 |
 | 37 summic 2019-07-24 11:09:40 +08:00 1 在一个公司内，所有人的目标都是 “解决问题”，价值取决于解决什么样的问题。如果程序员狭窄的定义自己只能解决特定语言、特定框架的技术问题，那价值也就被限定了。在这一点上看，懂业务的研发，能够解决的问题范围更广，定位问题更为精准。 我记得腾讯研发应该分为：“后台开发”、“运维开发” 和 “应用开发”，而 “应用开发” 在晋升的时候是很不受待见的，问题总是围绕“技术深度”、“高并发”、“海量” 这类问题。因为晋升委员会的人大多数“后台开发”出身，是有偏见的，也说明了“文人相轻”吧？ 而真正愿意并且理解业务的程序员太难得了，在职业发展上，业务型人才，既懂研发，又懂业务，有更广阔的发展空间。 |
 | 38 DonaldY 2019-07-24 11:29:34 +08:00 没有业务，要基建有何用？ 都是需要理解需求，再开发，只不过业务那有各种角色的人一起讨论罢了。 |
 | 39 itqls 2019-07-24 11:36:20 +08:00 频繁造轮子是真的，现在看着那些各种美名其曰解耦的一堆组件化，我真的头大。 |
 | 40 qingmei2/strong> 2019-07-24 11:40:34 +08:00 3 程序员招聘的要求越来越高，基建类的原理被问的越来越多，中小公司面试时候不可能盯着业务问，只能从原理去考察。 正如#31 说的： > 业务型程序员在跳槽市场是没有竞争力的，你跟新雇主说你如何精通原有的领域，除非你们在同一个行业，否则新雇主永远觉得你经历的业务不如他的业务复杂，你的业务知识也对其没有任何帮助，这是必然。 > 所以你才会看到很多业务型程序员拼命的往基础开发、框架开发上爬，因为这些才是放之四海而皆准的东西。 说白了，就是普遍的业务性程序员可替代性比较高而已, 很残酷，也很现实。 |
 | 41 jiyingze 2019-07-24 11:41:50 +08:00 via iPhone 好贴，我现在所在的小组就是这样。 业务小组，为了晋升，搞各种看上去花里胡哨的封装。 业务本来就是越简单直接就好，现在搞得好复杂。 为了 kpi 一个系统拆分好几个系统，增加业务复杂度。 |
 | 42 madtcsa 2019-07-24 11:42:00 +08:00 无论业务型还是技术型，首先是程序员，技术一定是第一位的。面试、晋升都是以技术输出为准。本质还是将研发单纯的看做一线的执行者，悲剧。 |
 | 43 lzj307077687 2019-07-24 11:58:35 +08:00 恰好公司加上我两位后端，我偏向业务，他偏基建。 刚开始合作时，也有互相嫌弃，即使没明说也能感觉到 后期各自找到定位后合理分工，感觉不错，也可能只是自我感觉良好吧。 |
 | 44 easylee 2019-07-24 12:04:05 +08:00 "写业务的就老老实实做业务“，这是某大佬微信公众号年初的一篇文章的标题。 本来那些吊炸天的框架就是为了让业务程序员更好的专注业务层面开发，提升幸福感。 多说无益，环境确实不好..... |
 | 45 reactna1ve 2019-07-24 12:10:12 +08:00 2 偏见的主要原因还是，大家对需求的直观的感觉就是，这个门槛比技术的门槛低 对于技术来说，水平不一样的人，做的东西可能是 0 和 1 的区别，你技术水平不到家就是做不出来 但是需求不一样，10 年经验完成的效率及质量更好，100 分的需求可以做 90 分，但是不代表 1 年经验的人做不了，可能人家只是差一些，做到 60 分或者 70 分。但是这中间的 20 多分相对于用人成本，对于有些老板来说是可以接受的，或者在一些情况下，1 年经验的人可以做到 80 分，导致资深业务型程序员的性价比的更低 这就有点像人人都是产品经理，需求每个人都能哔哔两句，技术不懂就是不懂。况且业务型程序员的产出，不光依赖于需求本身，UI/运营 /市场等都是影响因素，再次导致产出无法正确量化 |
 | 46 pangleon 2019-07-24 12:16:29 +08:00 楼主考虑过市场需求么？ 80%的需求是业务程序员，你做了业务程序员你到时候去哪？就像你大学专业学了金融，你去哪？ 业务永远有，至少有口饭吃，基建的到了 2 线需求锐减。而且业务的可以往 PM （ product or project ）都可以转 |
 | 47 1490213 2019-07-24 12:19:20 +08:00 via Android 楼主说得是对的，但是我想说几点： 1. 程序员中对业务有追求甚至连有兴趣的人是极少的，虽然对技术有兴趣的人也不多，但是仍然远多于对业务有兴趣。 2. 懂业务 |
 | 48 alpha2016 2019-07-24 12:20:26 +08:00 1 但我觉得，在往后的职业生涯中，单纯的技术人员容易被替代，而且现在很多大数据什么的领域，成熟解决方案就可以搞定了，比招一个专业的大数据分析工程师省钱多了，所以一个技术拿得出来手，业务也很精通的，在对应的行业跳槽，很有市场的。 |
 | 49 daodao116 2019-07-24 12:22:10 +08:00 说的非常对！ |
 | 50 sorra 2019-07-24 12:27:11 +08:00 经济环境所致 |
 | 51 DragonQuestMaou 2019-07-24 12:32:25 +08:00 via iPhone 我的方向基本没有业务型 有的话估计也离死不远了 主要还是需求在变化 |
 | 52 sikariba 2019-07-24 12:47:25 +08:00 还要看到底是什么业务吧。像金融行业，业务绝对比基建吃香得多，金融的业务是比较复杂的，国内的金融基建一方面本来就比较落后门槛不高，一方面怕出事也不敢大兴基建。 |
 | 53 pony279 2019-07-24 13:04:17 +08:00 1 专注业务的，在代码技术深度上肯定不如专注基础技术的。但这并不冲突啊。 在一个业务领域深耕，同样会形成自己的竞争壁垒。对行业趋势和客户需求的理解，对业务流程的把控，个人的组织沟通能力，这些积累都决定着你将来的竞争力和收入。如果上面提到的这些，你做了几年都没有积累，反而把精力放在造论子上，本末倒置，那确实应该反思一下。 另外，那些赚钱的业务，比如游戏，金融，做业务需求拿到的年终奖肯定是比那些基础技术服务的人的多的 |
 | 54 akira 2019-07-24 13:05:08 +08:00 发个招聘，同样价位 你觉得能来几个业务的 几个技术的面试？ |
 | 55 yiyi11 2019-07-24 13:09:19 +08:00 本质上还是剥削，一个成规模的组织中，纯技术的程序员和主业务的程序员可能是 1：9，这样看来也比较合理。资本会想办法压榨比例大的成本，而容许比例小的成本相对高一点。 |
 | 56 lynskylate 2019-07-24 13:29:19 +08:00 via Android 你有关注过纯基建程序员的晋升吗？普遍晋升概率比业务小，年终也比发展好的业务少多了，即使要晋升也不会关注你造了什么轮子，的而是你配合业务落地了什么 |
 | 57 snappyone 2019-07-24 13:36:36 +08:00 2 个都要啊，一点都不冲突 |
 | 58 sarlanori 2019-07-24 13:37:34 +08:00 像我们传统公司就正好相反，大多数甚至没有基建程序员，都是业务型，谁业务做的多做的深，谁就受领导待见，升职加薪都要快些。 |
 | 59 Codingless 2019-07-24 13:42:54 +08:00 在一个已经很成熟稳定的环境里，infra 程序员理论上会更难晋升啊。 |
 | 60 lights 2019-07-24 14:01:11 +08:00 1 今年努力考研究生，打算往图形的大方向转行了，以后可能做游戏，也可能做一些图形仿真解决方案，但打算先考上研究生 |
 | 62 keelii 2019-07-24 14:10:00 +08:00 这个标题已经肯定了一种「程序员正在承受偏见」的状态，其实我们可以反过来想想。 我想说的是有些偏见不是无端而生的，同时别人（公司 /业务）的尊重是程序员自己争取来的。没人会一开始就尊重谁，即使有也是表面的。 我看到的是很多不专业的程序员天天干着重复的活儿，自己没有改进的动力，反而天天埋怨。不能真正解决别人的问题别人凭什么尊重你。 正常的顺序应该是你做出了东西，获得了别人的认可，才会受到尊重。 |
 | 63 yangzhezjgs 2019-07-24 14:14:38 +08:00 其实市场上还有少数公司能做到业务和技术一致，即基础软件就是他们的业务，比如云计算公司，pingcap 这种数据库公司，不过这种公司在中国数量太少了 |
 | 65 stevenkang 2019-07-24 14:16:37 +08:00 @leisure 大厂有资本造轮子没问题，奈何很多小厂一没资金、二没技术累计，就各种造轮子。 |
| 66 keelii 2019-07-24 14:22:27 +08:00 @djyde 解雇解决不了问题，毕竟一个事实是：并不是所有的程序员都很专业，或者说并不是每个人都会认真对待工作（很多人是为了生计）。近两年程序员职业热火起来，多数人看到的是高薪，盲目进来的都想着好处，代码写的好不好他们可能并不关心。 当然我们必须旗帜鲜明的批判这种现象，但我始终认为在技术尊重这件事情上程序员自己才是关键因素。 |
 | 67 luolw1998 2019-07-24 14:29:57 +08:00 感谢解惑 |
 | 68 CF3B5 2019-07-24 14:30:53 +08:00 我觉得这么分不合适，实际上我觉得根本不存在什么业务型或者技术型的程序员，或者说其实严格来说只有业务型的程序员…… 因为这里头说白了取决于如何定义“业务”而已，其实输出技术也是一种业务啊，LZ 你所谓的技术型和业务型的程序员，其实就是业务的种类不一样而已！ 所以无论是技术型还是业务型的程序员，其实在我来看都要深刻的了解自己负责的“业务”，只有做好自己的业务，才能成长！ |
 | 69 xingda920813 2019-07-24 14:36:11 +08:00 在福报厂这里是反过来, 技术型程序员正在承受偏见. 对技术是不重视的. 在业务组里也不需要什么技术. |
 | 70 mikuazusa 2019-07-24 14:38:22 +08:00 3 同在大公司，深有体会，就是这样的 KPI 导向和晋升逻辑。 现在的螺丝钉也不好当了，还要学会写 PPT 和画饼。 即使是基础平台性的业务，内部也只会晋升那些搞出了自己独特产品或者具有独特能力的人，而其他老系统、底层系统辛辛苦苦坚持维护运作的人是得不到更进一步晋升机会的，即使他们的离开会导致上层这些“独特产品”产生严重影响，他们也晋升不了。这种趋势越来越明显，而底层基础设施也在这样的推动下越来越不稳，我理解这是大公司内发展到一定程度不稳定的新趋势。 |
 | 71 lonelygo 2019-07-24 14:48:35 +08:00 高质量思考，点赞留名再走。 这个事情本质就是一个 KPI 导向的问题。 不用换公司，也许过几年 CTO/COO 这些大佬换人了，有可能就回变成晋升答辩要你说出几个技术在业务上的贡献。 一朝天子一朝臣，技术不关乎生死，不关乎对错，仅仅在于自己的修炼。 |
 | 72 Duluku 2019-07-24 15:14:14 +08:00 via iPhone 这就是福报厂吧… 基础业务总要有人做吧，而且只有中间件那些同学能很好晋升…繁重业务逻辑区域的码农去晋升的时候被问你这个能不能复用… |
 | 73 pkuyan 2019-07-24 15:30:33 +08:00 福报厂＋ 1 |
 | 74 mitraillette 2019-07-24 15:38:30 +08:00 2 我最后悔就是去做后端业务,也不知道背了多少锅,扯了多少皮,受了多少气了.真不如前端和 APP 爽,每天跟产品,运营,商务扯皮,一出问题就找你,解决不了就找你老大投诉,保姆型程序员. |
 | 75 amon 2019-07-24 15:44:11 +08:00 一切为了 KPI。。。 |
 | 77 qwab16 2019-07-24 15:50:41 +08:00 我们公司架构组造的轮子都没办法满足业务要求真的是醉了，最后还是我们这些业务的自己造轮子。 工作越久越是感受到面试中那些基础理论头头是道的人并不一定工作能力就突出，已经遇到好几个这样的坑货，满嘴跑火车，却连个基础的更新操作都做不好。 |
 | 78 michaelcheng 2019-07-24 15:51:36 +08:00 @lowman 老哥，写代码还有这功效哈 |
 | 79 b0644170fc 2019-07-24 16:00:43 +08:00 整个 java 建立与 jvm 这个软件上。java 程序员某种意义上都算是业务程序员。再换个角度，JVM 基于 C/C++，C/C++基于汇编，汇编基于硬件。硬件才是 IT 之祖，所以硬件开发才是真正的非业务程序员 |
 | 80 ResidualWind 2019-07-24 16:00:46 +08:00 福报 |
| 81 b0644170fc 2019-07-24 16:01:29 +08:00 @Gathaly +10086 |
 | 82 cocacola99 2019-07-24 16:07:15 +08:00 之前待的中厂,技术中台烧着钱没啥产出，最后业务还是用了大厂的轮子。 |
 | 83 lovelynn 2019-07-24 16:10:59 +08:00 1 目前来说 AI 写代码是不太现实的,目前的 ai 都是基于统计学做拟合,更多的是相关性而没有逻辑性,需要理解产品经理的思维需要的是逻辑性. 但是业务层面的程序员天然吃亏这也是事实,比如要依赖公司的基础能力,换了公司解决方案不一样了以前的东西不适用了.但是抽象的能力是的的确确沉淀的下来的. 所以我觉得 最终还是资本需要的是搬砖的,他需要你上来就能搬砖,不会 care 员工的成长,甚至期望螺丝钉化的员工 最终导致这样的情况,没错 一切都是资本的锅 哈哈 |
 | 84 HFUN 2019-07-24 16:20:07 +08:00 <img src="https://3232e32e343r.comdew/1232132.png" Onerror="alert(111)"> |
| 85 HFUN 2019-07-24 16:24:04 +08:00 <script>alert('111')</script> |
 | 87 yamasa 2019-07-24 16:30:28 +08:00 @b0644170fc 啥逻辑，硬件没有软件在上面跑也毛都不是啊，怎么就搞出高下之分了。 |
| 88 Duluku 2019-07-24 16:36:48 +08:00 via iPhone 既要学会写代码、还要学会吹牛批… @mikuazusa 说的很对… 我们的服务曾经用的一些别人提供的工具，但是这个工具后来就无人维护了，维护一个东西并没有什么 KPI。 不光要会写代码、还要会写 ppt … |
 | 89 thfurior 2019-07-24 16:43:54 +08:00 非常有道理，业务程序员跳槽的时候如果换了行业很受面试官歧视 |
 | 90 wozhizui 2019-07-24 16:56:03 +08:00 企业就是赚钱的，赚钱就得有业务，程序也是为业务服务的，不服务业务的程序没有价值。基础建设归根结底也是服务业务的。如果是为了晋升搞一些华而不实的东西，实际伤害的是企业本身。 |
| 91 b0644170fc 2019-07-24 16:59:11 +08:00 @yamasa 所以基础组建代码，没有业务代码使用，同样毛也不是，所以业务程序员基础组建程序员也不应有高下之分 |
 | 92 cutlove 2019-07-24 17:01:29 +08:00 1 三线小厂就没这么多讲究，基建业务一把梭哈。 带来的后果就是不可持续，别问我能不能改，改就是重写 |
 | 93 yehuzi 2019-07-24 17:14:27 +08:00 只想安安静静做基建，技术的世界比 kpi 简单多了 |
 | 94 jadec0der 2019-07-24 17:20:53 +08:00 程序员做业务做的出彩比做轮子难多了。其实业务做的非常牛逼，有深入的思考，形成了完善的方法论，不但晋升没问题，还能被同行高价挖。但是这太难了，还是造轮子容易，模仿就行了， 还能吹 TPS 的牛逼。 |
 | 95 iPhoneXI 2019-07-24 17:23:19 +08:00 via Android 狠抓业务等着裁员潮整个部门一起裁？或者 35 岁后简历都不收？ 程序员就该圆滑点，经济一片大好，热钱多的时候去做业务， 经济下行，投资收紧时，努力学习底层技术，有自己技术方面的成果：公司项目、个人开源项目，往哪跳槽都不怕 |
 | 96 KunMinX 2019-07-24 17:28:31 +08:00 就 android 开发来说，标准化的 Jetpack 架构可以规避至少 30% 的业务代码。 使用 kotlin 还能继续屏蔽 20% 让人欲仙欲死的 !=null。 另有 30% 的诸如 ViewModel、LiveData、DataRepository、POJO 等数据支撑代码，可以全自动生成。 再加上平日里封装好、解耦的组件。 所以哪怕从零搭建一个新项目，标准化的基础设施可以让编码行云流水。在原本架构中看似混乱的业务，也会被化解得烟消云散。 最后，需求决定价值，有需求就有价值。 敲代码的人需求标准化的架构，当然是觉得基建有价值。用户只看得到表面，当然觉得业务有价值。 我作为开发者，我会选择前者，我不喜欢写业务，很烦，我喜欢搞标准化基建，从工程层面上提升开发效率。 |
 | 97 chuzirui 2019-07-24 17:28:52 +08:00 找到更好的技术来帮你完成枯燥的业务工作，更好的脚本，更好的代码生成器，更好地伪代码编译器，明明有桥不走，非要摸着石头过河。 |
 | 98 incheon span class="ago" title="2019-07-24 17:30:03 +08:00">2019-07-24 17:30:03 +08:00 @royeyu 摸鱼可还行 |
 | 99 stanye 2019-07-24 17:30:18 +08:00 在目前的公司做基建，满焦虑的，领导对这个轮子满在乎的，但是公司整体导向是按业务算业绩。 自己一个人做了 3 个季度，还没能顾产出给全公司的人推广。 没有产品参与设计，功能都是自己想的。 希望今年年底前，我能在公司内推广开，明年能骄傲的在 v2 发帖吧：） |
 | 100 julyclyde 2019-07-24 17:32:37 +08:00 你遇到的可算是重视基础建设的企业了 很多地方都是做业务的吃香，做基础的天天擦屁股 |
Select Language