Established in 2006, SAP Chengdu Research Institute is located in Zone B of Tianfu Software Park. Now, due to the continuous development of the research institute, it has been moved to Area E of Tianfu Software Park. Therefore, the stories full of joys and sorrows in the picture building have become indelible memories in the minds of some friends, and will disappear forever in the long river of history.
Why am I writing this article
SAP Chengdu Research Institute has many young partners who have just graduated from university. One of my friends whispered to me, “Why do developers in our company look so young? Where are the developers over 35? Is programmer really eat youth rice?”
These students think far ahead, which deserves praise. It seems that they are already thinking about their future career development path. As far as I know, SAP Chengdu Research Institute basically has several developers over 35 years old in each development team. Maybe it is because our company has a better work-life balance than other Internet companies, so everyone looks young, right? After all, it is not for nothing that SAP China Research Institute has been awarded the honor of best Employer among Foreign companies in China.
In the news – SAP has been named China’s Best Employer in 2017
Another young colleague asked me, “You’ve been in SAP Chengdu since you graduated, sitting in the same place writing code every day for 10 years. For the last 10 years, for the last five years, for the last year, you haven’t changed the way you code. Isn’t that boring? “My answer was,” I’m not in the same place. I was on the 3rd floor of software Park B6, then moved to the 4th floor, then moved to the 3rd floor, then moved to the 8th floor of E5. “My coding posture isn’t always the same, it’s getting more stooped as I get older.”
To be honest, it’s not possible to work on the same product for a long period of time without getting a little bit boring. In my case, in my seventh year, I went to my Manager Poseidon and told him that I felt my technical growth as a programmer had hit a wall, and that it had become my personal comfort zone to be on the development team delivering product features step by step, and I wanted to do something more challenging. Posei took me away from the standards team and asked me to do client-related work, such as handling customer incidents, going to customer site support, helping sales colleagues with orders, etc. Through these jobs, I can get close to Chinese CRM customers and understand their pain points in using SAP CRM. At the same time, I can help customers solve some practical problems through my efforts, which gives me a little sense of achievement. From this process, I also realized that no matter how good the technology is, if it can’t meet the actual needs of customers and help them run their business well, then the technology is worthless. I felt I still had a lot to learn about the business, so IN October 2014 I returned to the SAP product development team, where I have been ever since.
This is I avoid let oneself feel that development is a boring work of the first kind of way: when do you think it’s in the post have well enough, now has become your comfort zone, and communicate your manager confirm your feeling is true, discuss possible to engage in other more challenging, more helpful to the team on your own work.
I opened this official account on December 27, 2017. One reason is that I want to try a new way of technology sharing in the New Year. This new attempt can also help me to eliminate the boring feeling caused by long time development: I will share my knowledge through another platform other than SAP Community and communicate with people with different backgrounds and experiences in China.
This is my second way to avoid the boredom of long development hours: share your skills in a way and channel that you like.
Sharing may include but is not limited to writing on internal wiki/ Github, blogging on public platforms, or writing articles on wechat.
Some concerns/questions from younger colleagues about technology sharing:
1. Think you have nothing to share
Jerry’s advice: When we learned to write narrative essays in primary school, our Chinese teacher would teach us some routines. Writing technical articles is the same, the simplest routine: ask questions – analyze problems – solve problems. It is impossible not to encounter problems in our daily development work, and these problems become a source of technology sharing, no need to dream about it.
2. Think what you’re sharing is too easy. Most people will. No one will read it if I share it.
Jerry’s advice: First of all, it should be clear that the main purpose of personal technology sharing is to sort out, build and improve their own knowledge system. Whether others will benefit from it is a secondary issue. In my own experience, when writing the SAP Community blog, I often find myself unable to write or find myself unable to accurately express the ideas in my head. This phenomenon shows that I don’t really understand the point I’m writing about, and forces me to go back and do further research. The iteration and repetition of research -> writing -> research is the process in which I gradually formed my own routines and methodology for solving problems.
Nowadays, many gods write technical articles on their wechat official accounts. Why do we pay attention to many gods and read many of their articles? After half a month, we recall the articles we read before and find that we cannot remember the content of the articles. We read a lot of technical articles, but the more distant we feel from the gods?
The scientific findings above show that passive learning alone is the least efficient in terms of retention, while active learning appears to take more time and is the most cost-effective. My personal favorite method of active learning is to put what I’ve just learned into writing, “once for a lifetime.” Just like library functions in programming, once written, you can use them everywhere.
At the very least, even if your articles are truly unread, they are at least a personal log of your technical growth in the cloud. Every once in a while, say, a quarter, six months, or a year, when you review your previous journals, you’ll be able to tell clearly whether you’ve been making progress or not.
Let’s take a quiz: Can you recall exactly what specific development tasks you did each month for the past year? I can’t put it all together in my head. However, because I shared a lot of new things I learned at work every day or a problem I solved on SAP Community, and I made a small tool with CDS View to count these shared things, I could get information of various dimensions within 1 second.
For example, the total number of posts I share per year
In order of the number of articles shared per month
The numbers show that I wrote almost every day last May, as I had plenty of spare time in rural Germany, like: Jerry’s Long May Day holiday 2017: ABAP implementations of eight classic sorting algorithms
The third most frequent month was Last October, because I spent all of that time helping a domestic C4C customer to go online and wrote articles about specific problems encountered in the process of going online.
Or I want to remember what I did in November five years ago?
I can immediately recall from the article list that I was busy working with Poseidon to help the CCTV CRM project team deal with some urgent issues that affected the launch of the project.
3. Fear of mistakes in your writing and being criticized
J: There’s nothing to worry about. Everyone makes mistakes. If someone points them out, you can urge yourself to go back and study them further. If you do make a mistake, be honest and admit it and correct it. If you still think you’re right, be patient and discuss it with others – you can thank the people on the Internet who took their time to read your article and offer valuable advice. I have written a total of 549 articles on SAP Community, and I have never been criticized for any mistakes in my articles.
A third way to avoid boredom: automate your development as much as possible
By automation, I mean: If your daily routine involves trivial, repetitive tasks, and the rules you need to follow to accomplish those tasks can be clearly described in code, let the code do those tasks as much as possible, and put the time saved into truly creative work.
Some of my automation examples:
- The development of the CRM Addon was carried out on the S/4HANA system and it was inevitable to discuss some model design with S/4 colleagues. S/4 colleagues often need us to provide some input, some CRM old model information into some special format excel. The model information comes from different locations on different screens in SAPGUI. I counted 15 mouse clicks to fill in the complete information of a model, then CTRL+C and CTRL+V 7 times to paste the SAPGUI information into Excel. That doesn’t include where in SAPGUI you open a model and visually scan the information you need. Then each person was assigned 10 models to fill out.
I hate this kind of physical work!! But it’s work. It has to be done. What I did was, I wrote an ABAP program, input was a list of model names, and when I ran the program, the code would automatically grab all the information that needed to be filled in from the system, format it properly, and write the output to the system clipboard. Then ALL I had to do was open the Excel provided by my S/4 colleague and solve the problem with a CTRL V.
It took me an hour and a half to complete the little program, and a second to complete excel input. Of course, if I manually fill excel honestly, it may not take me an hour, but in this hour of physical labor, I have gained in technology?
One of the advantages of developing in SAPGUI over ABAP in Eclipse is that I personally think that any automation that you want to do in SAPGUI for your development system will eventually be automated. It’s just a matter of cost.
I’ve written more about these automation tools than I can count in my ABAP development career.
I put their code on my Github.
Some Small ABAP tools I write to improve daily work efficiency or just for fun
As stated above, I hate manual labor, and I want to do it in code.
2. Automation of Web application debugging.
If it’s a bug in the background code, what I often encounter is that EVERY time I have to do N clicks and jumps in the foreground to trigger my breakpoint in the background, and the background error I’m dealing with can’t be located without 10 times and 8 times debugging. So I usually write a little program to simulate what the foreground would do. It takes about a second to trigger a breakpoint.
I wrote an example in this blog post My Tips about how to Handle Complex and Tricky Issues
I call this small program, developed specifically for easy debugging, scaffolding.
(Note: the timing of this blog post reminds me of a terrible debugging experience. On April 30, 2014, it took a whole day of debugging and 8 hours to find the root cause of the problem.)
The development of these scaffolding programs can often increase your total time spent debugging errors, especially under the time pressure of Agile development, and some younger colleagues must be hesitant to take this approach. Especially if you are a foreground developer, it may be difficult at first to use the background API to simulate foreground operations. However, the more difficult things usually mean the greater rewards. For example, when you learn to breathe on both sides of the freestyle stroke with great effort, your direction in the water will be more stable and your progress will be faster. I haven’t learned yet.)
If it is a bug in the foreground JS code, but must rely on some specific data in the background to reproduce, and the generation of these data requires a lot of complex operations in the foreground, resulting in a long time to trigger a breakpoint in the foreground. To avoid this unnecessary wait before triggering breakpoints, A sophisticated solution is provided in UI5: Directly save backend DATA that causes foreground errors as MOCK DATA, and then use UI5’s MOCK SERVER to intercept and redirect requests sent from the foreground to the backend.
A Russian app has gone viral for automating many of life’s most mundane tasks with code: he has written scripts that text his wife to work late, ask for time off when he’s hungover, retrieve clients’ databases based on emails, and make coffee remotely with one click. ** The Github address for his script is at this link. This harvest of 30,000 + stars shows how important automation is in the minds of programmers.
conclusion
Having said that, I have three personal tips for young developers:
1. When you find that you have reached a growth plateau in your current job and that your current job has become your comfort zone, check with your manager to see if your feelings are really consistent with the facts. If so, explore the possibility of taking on tasks that are more challenging and allow you to grow faster.
2. Make a habit of accumulating and sharing your knowledge.
Automate everything that’s trivial, repetitive, or annoying at work.
Finally, back to the question in the title of the article: where are all the developers over 35 at SAP Chengdu Research Institute?
My answer: In your side. I quickly ran it through my head. Every agile development team at SAP Research In Chengdu has at least two or three senior developers over the age of 35, not to mention in their 40s. Our colleagues never call themselves by their English names inside the company, but simply call themselves Teacher XXX.
One of the most prominent developers at SAP Chengdu Research Institute is, of course, Ding Orlando, a senior data scientist known throughout the Southwest region for ai and machine learning. As far as I know, our scientist is also over 35 years old this year and is still a leading figure in the development field of SAP Chengdu Research Institute. Of course, I will not leak his wechat account, otherwise it will be poached by other companies, Poseidon will choke me to death.
Some of my friends who joined SAP Chengdu Research Institute in the same year with me are now more than 35 years old.
- Some go out to open their own companies, already financial freedom;
- Some go on to become CEO/CTO/CIO of other companies;
- Some have switched careers and become the financial/political elite;
- Some emigrate to other countries and continue to work in SAP industry there;
- The rest chose to stay in SAP Chengdu Research Institute.
The rest have become managers, product managers, architects, and others, like me, continue to develop.
In the following article, other senior colleagues of SAP Chengdu Research Institute will share their own stories: how to successfully transform from a developer to a successful XXXX. Young colleagues who are interested in this career development should look forward to it.
Appendix: Some articles on the Internet
1. The 860,000 reading articles on Zhihu are applicable to any industry: How to build your own knowledge system?
2. Why do I encourage engineers to blog
3. Why do some programmers slip through their mid-30s crisis
4. Why do some people stay the same after years of working
For more of Jerry’s original technical articles, please follow the public account “Wang Zixi” or scan the following QR code :\