SAP成都研究院35岁以上的开发人员都去哪儿了?

2022-10-21 10:06:59

2006年成立的SAP成都研究院，位于天府软件园B区。如今，因为研究院发展的不断壮大, 已经搬迁到天府软件园E区了，因此，发生在图片building各种充满悲欢离合的故事，已经成为一部分小伙伴脑海中难以磨灭的回忆，永远消逝于历史的长河之中。

我为什么要写这篇文章

SAP成都研究院有很多刚从大学毕业不久的年轻小伙伴加入。一起聊天时，有小伙伴悄悄向我打听，"咱们公司的开发人员们咋看起来都是年轻人？35岁以上的开发人员去哪儿了？难道程序员真是吃青春饭的？"

这些同学想的比较远，值得赞一个，看来TA已经在思考自己未来的职业发展之路了。据我所知，SAP成都研究院各个开发团队基本上都有几位35岁以上的开发人员，可能是因为我司的工作和生活的平衡做得相对其他互联网公司而言更好一些，所以使得大家看起来显得年轻吧? 毕竟SAP中国研究院连续获得中国外企里最佳雇主的荣誉并不是没有原因的。

上图来自新闻 - SAP再获“2017中国杰出雇主”称号

还有的年轻同事问我，“你一毕业就待在SAP成都，每天坐在同一个地方写代码，一写就是10年。过去10年，过去五年，去年都如此，连写代码的姿势都没变，不觉得枯燥吗？" 我的回答是: " 我没有在同一个地方待着，我最初是在软件园B6的3楼待着，后来又搬到4楼，然后又搬到3楼，然后搬到E5的8楼。我的写代码姿势也不是一成不变，随着年龄的增长，背越来越驼了。"

说实话，在同一个产品长时间工作，一点点都不觉得枯燥那也不太可能。拿我自己来说，在我工作的第7年, 我找到我的manager Poseidon谈心，我说我感觉作为一个程序员，我的技术成长遇到瓶颈了，现在在开发团队按部就班地交付产品功能已经成为我个人的舒适区，我想做一些更具挑战性的工作。于是Posei把我从标准开发团队摘出来，让我专门从事和客户相关的工作，比如处理客户incident, 去客户现场支持，帮助销售同事打单等等。通过这些工作我能够近距离接触中国的CRM客户，了解到他们使用SAP CRM的痛点，同时能通过我的努力帮助客户解决一些实际问题，有一点小小的成就感。从这个过程里我也意识到一个道理：再好的技术，如果不能满足客户的实际需要，不能帮助客户把业务运行好, 那么这个技术就没有价值。我觉得自己在业务上还有很多要学的，所以2014年10月我又重新回到了SAP产品开发团队，一直到现在。

这算是我避免让自己觉得开发是一项枯燥工作的第一种办法: 当你觉得在现在的岗位上已经做得足够好，现在的工作已经成为你的舒适区时，和你的manager沟通确认您的感觉是否属实，一起讨论有无可能从事别的更具挑战性, 对团队对您自己更有帮助的工作。

2017年12月27号我开了这个公众号，一个原因就是在新的一年里，想尝试一种新的技术分享方式，这种新的尝试也能帮助我消除长时间做开发产生的枯燥感：把我会的东西通过SAP Community之外的另一种平台分享出来，和国内的具有不同背景不同经历的各位一起交流。

这就是我想表达的避免长时间做开发工作产生枯燥感的第二种方式：把你自己会的技术用你喜欢的方式和渠道分享出来。

分享方式可以有但不局限于在公司内部wiki/github上写作，在公众平台上写博客，或者写微信公众号文章。

年轻同事关于技术分享的一些顾虑/问题：

1. 觉得没什么值得分享的

Jerry的建议：

小学我们学写记叙文时，语文老师会教我们一些套路。写技术文章也是如此，最简单的套路：提出问题-分析问题-解决问题。我们日常的开发工作中不可能不会遇到问题吧，这些问题就成为技术分享的来源, 不需要去空想。

2. 觉得自己分享的东西太简单了，大多数人肯定会。分享出来肯定没人看。

Jerry的建议:

首先要明确，个人的技术分享，最主要的目的是梳理，打造和完善自己的知识体系，至于别人会不会看了受益，这是次要问题。我自己的亲身体会，在写SAP community博客时，我经常遇到写着写着就写不下去，或者是发现自己无法用语言准确表述自己脑子里的想法。这种现象就说明我对我正在写的这个知识点实际上还未透彻理解，会迫使我回过头去做进一步深入研究。研究->写作->研究的这种迭代和不断重复，就是我逐渐形成自己解决问题的套路和方法论的过程。

现在很多大神都在自己的微信公众号上写技术文章，为什么我们关注了很多大神，拜读了他们很多文章，过了半个月再回忆之前读过的那些文章，发觉自己记不清文章的内容了。我们虽然读了很多技术文章，但是反而觉得和大神们的距离原来越远?

上图的科学研究结果表明，单纯的被动学习就其记忆留存率来说是最低效的，而主动学习表面上看会花费更多的时间，而性价比却是最高的。我个人最喜欢的主动学习方式就是把我新学到的东西写成文字，"一次劳神，终生受益"。就像编程开发里的库函数一样，写好之后可以到处用。

退一万步说，即使您的文章真的没人看，它们至少是您在云端的一份个人技术成长日志。每隔一段时间，比如一个季度，半年，一年，当你回顾你以前写过的这些日志，您能清晰地判断出这段时间内您的技术是有精进，还是在原地踏步。

我们来做个小测验：您能准确回忆起您过去一年内，每个月都做了哪些具体的开发任务？反正我是无法用脑子回忆起来。但是因为我在SAP community上分享了很多我每天工作中新学到的东西，或者是解决的一个难题，再加上我用CDS view做了一个统计这些分享的小工具，所以我能在1秒钟内得到各种维度的信息。

比如我每年总共分享的文章数

每个月分享的文章数从高到底排序

从数字能看出去年5月我几乎每天都会写一篇，因为那段时间在德国乡下，有大把业余时间可以支配, 比如：Jerry 2017年的五一小长假：8种经典排序算法的ABAP实现

第三多的月份是去年10月，因为那段时间全花在帮助一个国内C4C客户的上线支持上了，写的文章全是上线过程中遇到的具体问题。

再比如我想回忆5年前的11月份我干了哪些事情？

从文章列表我就能立即回忆起那段日子我正忙着和Poseidon一起，帮助*电视台CRM项目组共同处理影响项目上线的一些紧急问题。

3. 害怕自己写的文章里包含错误，被别人指责

Jerry的建议:

这个没什么担心的，是人都会犯错误，有人指出错误，可以督促自己回过头进一步研究验证。如果发现确实是自己错误，诚实地承认并且改正就行。如果依然觉得自己是对的，耐心和别人讨论 - 您应该感谢网络上花费自己时间仔细阅读了您的文章，并且提出宝贵意见的这些热心人。

我在SAP Community上一共写过549篇文章，没有出现过一次因为文章有错而被人指责的情况。

----

避免产生枯燥感的第三种方式：最大可能地让您的开发工作自动化起来

这里的自动化指的是: 如果您每天的日常工作中包含一些琐碎的，重复性的，并且完成这些工作需要遵循的规则是能够用代码清晰描述的，那么尽可能也让代码来完成它们，把节省下的时间投入到真正具有创造性的工作中去。

我的一些自动化例子:

CRM Addon的开发是在S/4HANA系统上进行的，不可避免的需要和S/4同事就一些模型设计进行讨论。S/4的同事经常需要我们提供一些输入，把一些CRM旧的模型信息填入到一些特殊格式的excel里。这些模型信息来自SAPGUI里不同屏幕的不同位置，填一个模型的完整信息我数过总共要点15次鼠标，然后7次CTRL+C 和CTRL+V, 才能把SAPGUI里的信息粘贴到excel里。这中间还不包含你打开一个模型，用肉眼去扫描需要的信息在SAPGUI什么地方。然后每个人分了10个模型需要填。

我对这种体力活简直是深恶痛绝!!! 然而这是工作, 必须得做。我的做法就是，写一个ABAP程序，输入是模型名称列表，执行这个程序，代码会自动从系统抓取所有需要填的信息，做恰当的格式化之后，把输出写到系统剪切板里。然后我只需要打开S/4同事提供的excel, 一个CTRL V就解决问题。

最后我花了1个半小时的时间完成这个小程序, 然后花了1秒钟完成excel的输入。当然我如果老老实实的手动去填excel, 也许花不了1个小时，但这1个小时的体力劳动里，我在技术有收获么？

用SAPGUI做开发，一个优于用ABAP in Eclipse之处在于，我个人认为，任何想在开发系统的SAPGUI里实现的自动化操作，最终都能实现自动化操作, 问题只是代价的大小而已。

我在自己的ABAP开发生涯里写过大量这种自动化工具，多得我自己都数不清了。

我把它们的代码放在了我的github上。

为了方便使用这些工具，我又写了一些管理这些工具的工具，方便我快速找到我想用的工具：

Some small ABAP tools I write to improve daily work efficiency or just for fun

目的如上面说的，我痛恨体力劳动，我要用代码来完成它们。

2. web应用调试的自动化。

如果是后台代码的bug，我经常遇到的情况是，每次我得在前台做N次的点击，跳转，才能触发我后台的断点，而我处理的后台错误没有10次8次的调试根本无法定位问题。每次断点触发之前的重复操作让我忍无可忍，所以我通常会自己写一个小程序模拟前台的操作，每次执行这个小程序，1秒钟即可触发断点。

我把其中一个例子写在了这篇blog里My Tips about how to handle complex and tricky issues

我把这种专门为了方便调试而开发的小程序称为脚手架。

(注: 这篇博客的发布时间让我回忆起那不堪回首的调试经历，2014年4月30日调试了整整一天，花费了8个小时最后才找到问题根源。)

这些脚手架程序的开发通常会增加您进行错误调试的总时间，特别是在敏捷开发的时间压力下，有的年轻同事一定会对是否采用这种方式有些犹豫。尤其当您是一位前台开发人员时，一开始可能会对如何使用后台API来模拟前台操作感到比较困难。然而越困难的事情通常意味着越大的回报，比如您花大力气学会了*泳的双侧换气之后，您在水中的前进方向将更稳定，前进速度更快(我看这篇文章*泳换气，只用一边怎么行？里介绍的，我至今还未学会)

如果是前台js代码的bug, 但是必须依赖于后台某些特定的数据才能重现，而生成这些数据又需要在前台做很多复杂的操作，这导致每触发一次前台的断点要花很多时间。为了避免这种触发断点前不必要的等待，UI5里面提供了成熟的解决方案：直接把能引起前台出错的后台数据保存下来作为MOCK DATA, 然后使用UI5的MOCK SERVER把前台发向后台的请求拦截并重定向到MOCK SERVER.

前段时间有个俄罗斯程序猿火了，因为他已经将生活中的很多琐事也用代码自动化起来了：他写了一堆脚本，会给老婆发加班短信、会在宿醉不醒时给自己请假、会自动根据邮件恢复客户的数据库、还可以一键远程煮咖啡。他的脚本所在的github地址见这个链接。收获的这3万+的星，说明自动化在程序猿心中的重要程度。

总结

啰嗦了这么多，对于年轻的开发同事们我的三点个人建议:

1. 当您发现您在当前工作岗位上已经进入成长瓶颈期，现在的工作内容已经成为您的舒适区时，和您的管理者交流，确认您的感觉是否真的和事实一致。如果属实，一起探讨有没有可能去做一些更有挑战性，能让您更快成长的任务。

2. 养成知识积累并分享出来的习惯。

3. 将您工作中一切琐碎，重复，让您抓狂的事情自动化起来。

最后，回到文章题目的问题：SAP成都研究院35岁以上的开发人员都到哪儿去了？

我的回答：就在您的身边。我迅速在脑子里过了一遍，成都SAP研究院每个敏捷开发小组都有至少两到三位35岁以上的资深开发人员，别说35岁，40多岁的都有。咱们同事在公司内部都从不叫他们的英文名字，而直接叫某某老师。

SAP成都研究院开发人员里最杰出的代表，当然是以人工智能和机器学习闻名于整个西南地区的高级数据科学家Ding Orlando。据我所知我们这位科学家今年也超过三十五岁了，依然是SAP成都研究院开发领域内的旗帜人物。当然我是不会把他的微信号泄露出来的，不然被其他公司挖走，Poseidon会把我掐死。

另一部分和我同一年进SAP成都研究院的小伙伴们，时光荏苒，现在大都已经超过35岁了。