这是一个创建于 1954 天前的主题，其中的信息可能已经有所发展或是发生改变。
大公司似乎有个通病，就是没有给做业务的技术人员安全感以及应有的回报。似乎做技术、做基础建设的就要比做业务的更有价值。前者能为团队提效，能向外输出能力，这当然能作为绩效和晋升的评判标准。但为何一个能理解业务需求，按时交付代码，迅速拉通业务上下游的业务型程序员，也被要求做出「技术影响力」才可以晋升？
当然，优秀的程序员两者都应该有，但总得有一个侧重点，因为人的时间是有限的。而这种畸形的评判标准，会让做业务的程序员产生严重的焦虑 —— 我光做业务时间已经不够了，我哪有时间还去做基础建设呢？
不光如此，它还会造成另一种副作用，就是做业务的程序员，在想方设法地去造轮子，创造伪需求。明明用原生的 API 就能搞定的事，非要「封装」一下，除了制造一种「高级感」，一无是处，有时听到这些方案都会觉得尴尬。
我不是反对造轮子，我是反对造不应该造的轮子。这样的轮子造出来了，PPT 写好了，做的人晋升了，维不维护，那是之后再说吧。苦的还是用它来做业务的队友们。
真正的基础建设，是让使用者觉得好用，方便，靠谱，解决了真正的痛点，让业务跑得更快，更稳，用了这种技术，原本要写两天的程序，现在两小时能完成。这些有意义的基础建设，不是在办公室开两小时会就能想出来的，是业务刚好遇到对应的场景才做得出来的。但是，谁都不愿意承认这个事实，因为你不搞技术，你就没有所谓的技术影响力，你就晋升不了了。
我能理解那些瞎造轮子的人是制度使然。游戏规则就是这样，你想玩得好，无论规则多傻逼，都要按照规则去玩。
有人说，你就做业务，太容易被取代了。我想说，做业务，也有分做得好不好的，你做什么事情可以做不好还不被取代？除非有一种编程语言只有你会。还有人说，未来 AI 都能写代码了。我只知道，现在我连一个靠谱的能帮我糊 HTML 页面的 AI 我都没见到，50 年内，可以出现一个能理解产品经理的需求，自动写出符合需求的代码的 AI ?
所以，技术人员的晋升标准应该改为有两个不同的方向 —— 业务型人员和技术型人员。两者都应该有不同的评判标准，两个不同的晋升体系。让做业务的人专于完成业务，让做技术的人专心服务业务。没有谁比谁的价值低。
（利益相关：我这三年做的几乎都是基建）
当然，优秀的程序员两者都应该有，但总得有一个侧重点，因为人的时间是有限的。而这种畸形的评判标准，会让做业务的程序员产生严重的焦虑 —— 我光做业务时间已经不够了，我哪有时间还去做基础建设呢？
不光如此，它还会造成另一种副作用，就是做业务的程序员，在想方设法地去造轮子，创造伪需求。明明用原生的 API 就能搞定的事，非要「封装」一下，除了制造一种「高级感」，一无是处，有时听到这些方案都会觉得尴尬。
我不是反对造轮子，我是反对造不应该造的轮子。这样的轮子造出来了，PPT 写好了，做的人晋升了，维不维护，那是之后再说吧。苦的还是用它来做业务的队友们。
真正的基础建设，是让使用者觉得好用，方便，靠谱，解决了真正的痛点，让业务跑得更快，更稳，用了这种技术，原本要写两天的程序，现在两小时能完成。这些有意义的基础建设，不是在办公室开两小时会就能想出来的，是业务刚好遇到对应的场景才做得出来的。但是，谁都不愿意承认这个事实，因为你不搞技术，你就没有所谓的技术影响力，你就晋升不了了。
我能理解那些瞎造轮子的人是制度使然。游戏规则就是这样，你想玩得好，无论规则多傻逼，都要按照规则去玩。
有人说，你就做业务，太容易被取代了。我想说，做业务，也有分做得好不好的，你做什么事情可以做不好还不被取代？除非有一种编程语言只有你会。还有人说，未来 AI 都能写代码了。我只知道，现在我连一个靠谱的能帮我糊 HTML 页面的 AI 我都没见到，50 年内，可以出现一个能理解产品经理的需求，自动写出符合需求的代码的 AI ?
所以，技术人员的晋升标准应该改为有两个不同的方向 —— 业务型人员和技术型人员。两者都应该有不同的评判标准，两个不同的晋升体系。让做业务的人专于完成业务，让做技术的人专心服务业务。没有谁比谁的价值低。
（利益相关：我这三年做的几乎都是基建）
 |
101
djyde OP @julyclyde #100 那你就错了，我指的是那些重视业务，程序员在完成业务进行考核的时候，就 judge 你技术建设的情况。
|
 |
102
tachikomachann 2019-07-24 17:42:53 +08:00 via Android  1
基建类程序员，在轮子初步完成进入稳定期后，会沦为前面说的客服型程序员。也是很惨的。
|
 |
103
gaigechunfeng 2019-07-24 17:46:39 +08:00
@Duluku 哈哈，看到你这个笑了。切个图还要求复用。复用是吧，你丢一个 button 给他，完美复用
|
 |
104
Aresxue 2019-07-24 17:55:25 +08:00
没啥偏见吧。毕竟国内还是业务导向型，业务才是一个企业的护城河。像阿里就相当看中产出，搞基础建设的反而晋升较慢（但起点相对高点）。不过搞基础建设也不是瞎搞，技术的迭代是为了更好地服务于业务，这两块都要抓只不过会有不同侧重而已。
|
 |
105
geekjc 2019-07-24 17:57:50 +08:00
认同你这种看法
|
 |
106
Kei 2019-07-24 18:00:43 +08:00
挺在理的，但是现实状况下，业务类只能往 PM 发展……
|
 |
107
tyrealgray 2019-07-24 18:06:04 +08:00
其实是国内把编程搞成了劳动密集型产业，没有技术就用人力和加班堆出来。给劳动密集型产业打工的不都这样吗？
|
 |
108
arthas2234 2019-07-24 18:31:35 +08:00
业务程序员也有优势，那就是深挖一个业务领域，成为一个领域的专家也是很有优势的，不容易被替代
像以前供应链，证券这些业务为导向，业务经验往往比技术更重要 |
 |
109
ai277014717 2019-07-24 19:03:20 +08:00
确实受偏见，一但离职要从头开始。另外感觉做业务要理解透彻。不然很难晋升。
|
 |
110
enchilada2020 2019-07-24 19:06:02 +08:00 via Android
@momocraft 您能具体聊聊 SAP 吗
|
 |
112
a15819620038 2019-07-24 19:33:23 +08:00
业务程序员要是摊上个爆款，年终奖那可是相当的多吧
|
 |
113
chiu 2019-07-24 19:34:55 +08:00 via Android
这个头像我记得！是大佬！
|
 |
114
Jex 2019-07-24 20:29:03 +08:00
隔壁刚炒掉了运维：
https://v2ex.com/t/585867 |
 |
115
myliang 2019-07-24 20:45:52 +08:00 via Android
所以需要业余时间自己造轮子进步啊
|
 |
116
Antidictator 2019-07-25 02:05:15 +08:00
@lights 同今年考研，加油。
|
 |
117
charlie21 2019-07-25 03:28:59 +08:00
不分又怎样？
|
 |
118
xx19941215 2019-07-25 07:51:01 +08:00 via iPhone
看了头像 去了楼主博客 看了几片文章 嗯 很浓的王小波 风格 是大佬
|
 |
119
lights 2019-07-25 07:57:04 +08:00 via iPhone
@Antidictator 大兄弟睡得太晚了吧……
|
|
120
lights 2019-07-25 07:57:57 +08:00 via iPhone
@Antidictator 推荐用褪黑素调节一下生物钟，早点睡吧，我买的牌子是健安喜，京东有售
|
 |
121
Myprincess 2019-07-25 08:40:42 +08:00
要是我,如果程序员在简历上备注:业务型.会优先录用的.并且工资要比普通给的高 30%.
|
 |
123
qiumaoyuan 2019-07-25 09:10:06 +08:00
我觉得其实面向业务的程序，复杂度大很多，更需要良好的设计。
|
 |
124
Torpedo 2019-07-25 10:16:12 +08:00
这就看你的是什么公司了。实质上来说实际做事的工作相对容易在公司是一个底层。特别是大公司
|
|
125
Antidictator 2019-07-25 10:21:31 +08:00
@lights 好的谢谢
|
 |
126
StarkWhite 2019-07-25 10:35:00 +08:00
一直在填坑和挖坑的业务程序员路过。。。
|
 |
127
viamcc 2019-07-25 11:29:58 +08:00 3
还有一个问题是很多人述职的时候不会写 PPT，可以如下参考：
a) 面临 XX 大促 /YY 业务节点的研发任务，你作为小 leader，通过如何如何的手段确保了高质量的版本研发上线，最终 成功地支撑了多少多少的业务增长，同时为后续活动累积了经验 （这叫业务向导） b) 主导并推动了某某组件 /某某框架 /某某重构的落地，使得原有耗时 XX 天，bug 率 YY 高的研发需求研发周期减少了 aa%，bug 减少了 bb% （这叫有成效的研发优化） c) 面对小 a 离职 /小 b 不开心 /小 c 成长缓慢 /团队配合不默契的情况，采取了 XXOO 的手段，稳定了团队结构 /减少了小 a 的影响 /帮助小 c 迅速提升能力 /提升了团队总体的研发效率 （这叫团队建设） d) 和 XYZ 团队配合，推动改进了需求评审研发测试上线的流程，使得原有流程变快了 aa%（这叫流程改进，不过要将这个记得商业互吹捧一下兄弟团队） |
|
128
lights 2019-07-25 11:39:51 +08:00 via iPhone
@brust 我吃了一两个星期，现在准备停了，生物钟已经完全改过来了。晚上九点多开始犯困，一会儿就睡着了，早晨五点多醒，然后去运动。感觉还好
我也有几次吃完睡不着，但不是褪黑素的问题，是我太焦虑了，刷了一晚上的手机导致的 |
 |
129
howell5 2019-07-25 11:52:54 +08:00
那你觉得这样的业务型程序员如何，对于业务代码从来都是大干快上，面条代码堆积如。我不是说什么都要有架构，有封装。而是明明可以用 for 循环或者 table drive 的思路去做的。非要写重复代码。一个 50 行的 UI 代码。可以在同一个文件复制五遍。不考虑维护性和扩展性，帮他改完了，还说有学习成本。搞坏了代码...
|
 |
130
alfa 2019-07-25 11:56:30 +08:00
剑宗、气宗
|
 |
132
lynskylate 2019-07-25 12:29:00 +08:00 via Android
@Duluku #72 你是不是对中间件有什么误解，中间件绝逼福报厂晋升最慢的几个部门了，容易背锅，维护基础组件也没什么 kpi，做得好是你应该的，还要天天答疑做客服
|
 |
133
sanSansan 2019-07-25 15:27:53 +08:00
我觉得未来的趋势，应该会分化成两极：一种就是专门搞基础建设的程序员；另一种就是利用这些基础设施快速开发的业务型程序员。而且那些搞基础建设的程序员会往云厂商去集中，大部分的企业只留业务型程序员，业务程序员会用云厂商提供的基础建设就好了。
|
 |
134
hetech 2019-07-25 15:47:49 +08:00
@lynskylate 赞同。目前在做基础设施，很少做业务。如果基础设施很成熟的话，自我提升的空间很小了（ roi 太低）。到晋升的时候，还不如做业务的同事有优势。
|
 |
135
nodeny 2019-07-25 16:34:08 +08:00
挺在理的
|
 |
136
lucienhsu 2019-07-25 16:43:15 +08:00
我觉得我自己就是一名业务程序员，在技术的自信上一直不够。
不过，这两年也觉醒中，通过业余时间学习恢复自己在技术上的自信，更好的服务于业务的开发。 |
 |
137
HWH 2019-07-25 17:11:00 +08:00
目测版主是阿里的可能性比较大。
业务开发只是门槛比较低，大多数开发入行时应该多数是从业务开始做起的，后期根据机遇或者自身能力的证明，被别人认可，分配一些基数建设的工作。 看不起的大多数是同行，够不到的才香。 |
 |
138
miniwade514 2019-07-25 17:25:11 +08:00
你是不是在阿里😏
|
 |
139
sesmond 2019-07-25 17:48:53 +08:00
然而我觉得做业务比做基础强多了。不懂业务的程序员不是好程序员。
|
 |
140
amwyyyy 2019-07-25 18:08:44 +08:00
@julyclyde 我司就是，业务团队各种上光荣榜，年终总结会，CEO 感谢了一堆业务线的人，最后才点了下基础团队经理的名。😂
|
 |
141
neverfull 2021-03-20 20:11:23 +08:00
从业多年，做过前端，做过后端，也参与过平台级的 PASS 软件，自己也曾经思考过，到底是在做业务，还是做技术呢？如果是一直在做业务，那么它的技术性到底体现在哪里？最近自己也逐渐想明白了，无论做什么，你都得把代码写好，降本提效，很多时候业务的复杂性一点也不比基础技术低，只是他们所要解决的问题不同而已，并没有本质上的区别。做业务时，你需要面对很多形形色色的人，它所面临的问题也是随着时间而变化的，往往会面临更大的挑战；而做基础技术时，它所面临的问题比较单一，面向的人员也不会很复杂，但是它要求你持续在一个领域投入，静待花开，这不是每个人都能坚持下来的。但是除了做业务或是技术 ，其实我们还需要更多的其它能力，比如结构化思考能力、团队协作能力、项目管理能力，特别是快速学习能力等等这些通用的软性能力。如果你是一位团队 TL，你还得思考如何建设团队？如何激励每位团队成员，以帮助他们成长？你也得帮团队同学定目标和确定方向，做好目标规划和关键策略的分解，并保证落实到位。做业务也好，做技术也好，很多时候得看我们是不是愿意把它做好，是不是自己把它想得太简单了？在我看来，做不好业务的，也做不好技术；同样的，做不好技术的，也做不好业务，如果大家对「好」的理解是正向且一致的话，:)
|
Select Language