SAP Chengdu Research Institute, established in 2006, is located in Zone B of Tianfu Software Park. Nowadays, due to the continuous growth of the research institute, it has been relocated to Zone E of Tianfu Software Park. Therefore, the various stories full of joys and sorrows that occurred in the picture building have become indelible memories in the minds of some of the friends, and will forever disappear in history. In the long river.
Why should I write this article
SAP Chengdu Research Institute has many young partners who have just graduated from university to join. When chatting together, a small partner asked me quietly, "The developers in our company look like young people? Where are the developers over 35 years old? Do programmers really eat their youth?"
These classmates think far away, which is worthy of praise. It seems that they are already thinking about their future career development. As far as I know, each development team of SAP Chengdu Research Institute basically has several developers over 35 years old. It may be because our company’s work-life balance is better than other Internet companies, so Everyone looks young, right? After all, it is not without reason that SAP China Research Institute has continuously won the honor of Best Employer among Chinese foreign companies.
The picture above is from news- SAP won the title of "2017 China Top Employer" again
Some young colleagues asked me, “ You stayed in SAP Chengdu as soon as you graduated . You sit in the same place and write code every day for 10 years. The past 10 years, the past five years, and the last year have been the same. It’s the same, don’t you feel boring? " My answer is: "I didn’t stay in the same place. I first stayed on the 3rd floor of Software Park B6, then moved to the 4th floor, and then moved to the 3rd floor. , And then moved to the 8th floor of E5. My code writing posture is not static. As I grow older, my back becomes more and more hunched."
To be honest, it's impossible to work long hours on the same product without feeling boring at all. Take myself as an example. In the 7th year of my work, I found my manager Poseidon to talk. I said that I feel that as a programmer, my technical growth has encountered a bottleneck. Now the development team has delivered product functions step by step. To become my personal comfort zone , I want to do more challenging tasks. So Posei took me out of the standard development team and asked me to specialize in customer-related tasks, such as handling customer incidents, going to customer site support, helping sales colleagues to make orders, and so on. Through these work, I can get close to Chinese CRM customers, understand their pain points in using SAP CRM, and at the same time help customers solve some practical problems through my efforts, and have a little sense of accomplishment. From this process, I also realized a truth: even the best technology, if it can't meet the actual needs of customers, and can't help customers run their business well, then this technology has no value. I think I still have a lot to learn in business, so in October 2014 I returned to the SAP product development team, and it has been up until now.
This is my first way to avoid making myself feel that development is a boring job : When you feel that you have done well enough in your current position, and your current job has become your comfort zone, communicate with your manager to confirm Whether your feelings are true, discuss together whether it is possible to engage in other tasks that are more challenging and more helpful to the team and yourself.
I opened this official account on December 27, 2017. One reason is that in the new year, I want to try a new way of technology sharing. This new attempt can also help me eliminate the boringness of long-term development. Feelings: I will share what I know through another platform besides SAP Community, and communicate with people with different backgrounds and experiences in China.
This is the second way I want to express to avoid the boring feeling of doing development work for a long time: share the technology you know in the way and channel you like.
Sharing methods can include, but are not limited to, writing on the company's internal wiki/github, blogging on the public platform, or writing articles on WeChat public accounts.
Some concerns/problems of young colleagues about technology sharing:
1. I think there is nothing worth sharing
Jerry's suggestion: When
we learn to write narrative in elementary school, the Chinese teacher will teach us some routines. The same is true for writing technical articles, the simplest way: ask questions-analyze the problem-solve the problem . It is impossible that we will not encounter problems in our daily development work. These problems become the source of technology sharing, and there is no need to dream.
2. I feel that what I share is too simple, most people will definitely be. No one will read it if shared.
Jerry's suggestion:
First of all, we must make it clear that the main purpose of personal technology sharing is to sort out, build and improve our own knowledge system . As for whether others will benefit from it, this is a secondary question. From my own personal experience, when writing a SAP community blog, I often encounter that I can’t write as I write, or I find myself unable to accurately express the ideas in my mind in words. This phenomenon shows that I have not yet fully understood the knowledge point I am writing, and it will force me to go back and do further research. The iterative and constant repetition of research -> writing -> research is the process by which I gradually formed my own problem-solving routines and methodology.
Nowadays, many great gods write technical articles on their WeChat public accounts. Why do we follow so many great gods and read many of their articles, and after half a month, I recall the articles I read before, and find that I can’t remember the content of the articles. Up. Although we have read a lot of technical articles, but on the contrary, we feel that the farther away we are from the great gods?
The scientific research results in the above figure show that purely passive learning is the least effective in terms of its memory retention rate, while active learning on the surface will take more time, but the cost performance is the highest. My personal favorite way of active learning is to write what I have learned in words, "One time effort, lifelong benefit". Just like library functions in programming development, they can be used everywhere after they are written.
Take a step back and say that even if your articles are really not read, they are at least a log of your personal technical growth in the cloud . Every once in a while, such as a quarter, half a year, or a year, when you review the logs you have written before, you can clearly determine whether your technology has improved during this period or whether you are staying in place.
Let's take a quiz: Can you accurately recall what specific development tasks you have done every month in the past year? Anyway, I can't remember it in my head. But because I shared a lot of new things I learned in my daily work or a problem that I solved on the SAP community, and I used CDS view to make a small tool to count these shares, so I can do it in 1 second Obtain various dimensions of information in the clock.
For example, the total number of articles I share each year
The number of articles shared each month is sorted from highest to lowest
It can be seen from the figures that I wrote an article almost every day in May last year, because during that time in the German countryside, there was a lot of spare time at your disposal, for example: Jerry's May Day holiday in 2017: ABAP with 8 classic sorting algorithms achieve
The third most frequent month was October last year, because that time was spent helping a domestic C4C customer on-line support, and the articles written were all specific problems encountered during the on-line process.
For another example, I want to recall what I did in November 5 years ago?
From the article list, I can immediately recall that I was busy working with Poseidon to help the CRM project team of CCTV jointly deal with some urgent issues that affected the launch of the project.
3. Fear of being blamed by others if there are errors in the article written by yourself
Jerry's suggestion:
There is nothing to worry about. People make mistakes. If someone points out a mistake, you can urge yourself to go back and further research and verify. If you find that you are wrong, just admit it honestly and correct it. If you still feel that you are right, be patient and discuss with others-you should be grateful to these enthusiastic people on the Internet who spend their time carefully reading your article and giving valuable comments.
I have written a total of 549 articles on SAP Community, and I have never been accused of errors in the articles.
The third way to avoid boring feeling: to automate your development work as much as possible
The automation here refers to: If your daily work contains some trivial, repetitive, and the rules that need to be followed to complete these tasks can be clearly described in code, then let the code to complete them as much as possible, and The time saved is devoted to truly creative work.
Some of my automation examples:
- The development of CRM Addon is carried out on the S/4HANA system, and it is inevitable to discuss some model design with S/4 colleagues. S/4 colleagues often need us to provide some input, fill in some old CRM model information into some special format excel. The model information comes from different positions on different screens in SAPGUI. I have counted 15 mouse clicks to fill in the complete information of a model , and then 7 times CTRL+C and CTRL+V to paste the information in SAPGUI into excel. This does not include opening a model and scanning with the naked eye where the required information is in SAPGUI. Then everyone has 10 models to fill in.
I absolutely hate this kind of physical work!!! However, this is work and must be done. My approach is to write an ABAP program, the input is a list of model names, execute this program, the code will automatically grab all the information that needs to be filled from the system, after proper formatting, write the output to the system clipboard. Then I only need to open the excel provided by my S/4 colleague, and a CTRL V will solve the problem.
In the end, it took me 1.5 hours to complete this small program, and then it took 1 second to complete the excel input. Of course, if I honestly fill in excel manually, it may not take an hour, but in this one hour of manual labor, do I have any gains in technology?
One advantage of using SAPGUI for development is that ABAP in Eclipse is better than using ABAP in Eclipse. I personally think that any automated operation that you want to achieve in the SAPGUI of the development system can eventually be automated. The problem is only the price.
I have written a lot of these automation tools in my ABAP development career, and I can't even count them.
I put their code on my github .
In order to facilitate the use of these tools, I wrote some tools to manage these tools so that I can quickly find the tools I want to use:
Some small ABAP tools I write to improve daily work efficiency or just for fun
The purpose is as mentioned above, I hate manual labor, I want to use code to complete them .
2. Automation of web application debugging.
If it is a bug in the background code, I often encounter a situation that every time I have to do N clicks and jumps in the foreground to trigger my background breakpoint, and the background error I deal with is not 10 times 8 times Debugging cannot locate the problem at all. I can't bear the repeated operations before each breakpoint is triggered, so I usually write a small program myself to simulate the operation of the foreground. Each time I execute this small program, the breakpoint can be triggered in 1 second.
I wrote one of the examples in this blog My Tips about how to handle complex and tricky issues
I call this kind of small program specially developed to facilitate debugging as scaffolding.
(Note: The publication time of this blog reminds me of the unbearable debugging experience. It took a whole day of debugging on April 30, 2014, and it took 8 hours to find the root of the problem.)
The development of these scaffolding programs will usually increase your total time for error debugging, especially under the time pressure of agile development. Some young colleagues will definitely hesitate to adopt this method. Especially when you are a front-end developer, you may find it difficult to use the back-end API to simulate front-end operations at first. However, the more difficult things usually mean the greater the reward. For example, after you have learned the bilateral ventilation of freestyle with great effort, your heading in the water will be more stable and faster (I read this article on freestyle change Qi, how can I use only one side? It was introduced in, I haven't learned yet)
If it is a bug in the foreground js code, it must rely on some specific data in the background to reproduce, and generating these data requires a lot of complex operations in the foreground, which causes it to take a lot of time to trigger a breakpoint in the foreground. In order to avoid unnecessary waiting before triggering a breakpoint, UI5 provides a mature solution: directly save the background data that can cause errors in the foreground as MOCK DATA, and then use UI5's MOCK SERVER to send the request from the foreground to the background Intercept and redirect to MOCK SERVER.
Some time ago, there was a Russian programmer who became popular, because he has already automated many trivial things in life with code: he wrote a bunch of scripts, ** will send overtime text messages to his wife, and will give it to his wife when he is not awake. Ask for leave by yourself, automatically restore the customer’s database based on emails, and make coffee remotely with one click. **See this link for the github address where his script is located . The harvest of 30,000+ stars illustrates the importance of automation in the minds of programmers.
to sum up
After so long, I have three personal suggestions for young developers :
1. When you find that you have entered a growth bottleneck in your current job position, and your current job content has become your comfort zone, communicate with your manager to confirm whether your feelings are really consistent with the facts. If it is true, discuss whether it is possible to do some more challenging tasks that will allow you to grow faster.
2. Develop the habit of accumulating and sharing knowledge.
3. Automate all the trivial, repetitive things in your work that make you crazy.
Finally, back to the topic of the article: Where are all the developers over 35 years of age at SAP Chengdu Research Institute?
My answer: right by your side. I quickly went through it in my head. Each agile development team of the Chengdu SAP Research Institute has at least two to three senior developers over 35 years old, let alone those in their 40s. Our colleagues never call their English names in the company, but directly call them teacher XX.
The most outstanding representative of the developers of the SAP Chengdu Research Institute is of course Ding Orlando, a senior data scientist who is well-known throughout the southwestern region for artificial intelligence and machine learning . As far as I know, our scientist is over thirty-five years old this year, and he is still the leading figure in the development field of the SAP Chengdu Research Institute. Of course, I will not leak his WeChat account, otherwise I will be poached by other companies and Poseidon will choke me to death.
The other part of the friends who entered the SAP Chengdu Research Institute the same year as me, time flies, most of them are now over 35 years old.
-
Some went out to start their own companies, already financial freedom;
-
Some went to other companies to become CEO/CTO/CIO;
-
Some have changed careers and become financial/political elites;
-
Some immigrate to other countries and continue to engage in the SAP industry there;
-
The remaining part chose to stay in SAP Chengdu Research Institute.
Some of the remaining parts have become managers, some have become product managers, some have become architects, and others, like me, are still developing.
In the next public article, other senior colleagues from SAP Chengdu Research Institute will share their stories: how to successfully transform from a developer to a successful XXXX . Young colleagues who are interested in this career development, stay tuned.
Appendix: Some articles on the Internet
1. Know the articles read more than 860,000 times, applicable to any industry: How to build your own knowledge system?
2. Why do I encourage engineers to blog
3. Why do some programmers survive the 35-year-old midlife crisis quietly
4. Why do some people still work the same for many years
To get more Jerry's original technical articles, please follow the public account "Wang Zixi" or scan the following QR code: