SAP成都研究院35歲以上的開發人員都去哪兒了?

時間 2019-11-19

標籤 sap 研究院歲以上開發人員哪兒简体版

原文原文鏈接

2006年成立的SAP成都研究院，位於天府軟件園B區。現在，由於研究院發展的不斷壯大, 已經搬遷到天府軟件園E區了，所以，發生在圖片building各類充滿悲歡離合的故事，已經成爲一部分小夥伴腦海中難以磨滅的回憶，永遠消逝於歷史的長河之中。html

我爲何要寫這篇文章

SAP成都研究院有不少剛從大學畢業不久的年輕小夥伴加入。一塊兒聊天時，有小夥伴悄悄向我打聽，"我們公司的開發人員們咋看起來都是年輕人？35歲以上的開發人員去哪兒了？難道程序員真是吃青春飯的？"git

這些同窗想的比較遠，值得贊一個，看來TA已經在思考本身將來的職業發展之路了。據我所知，SAP成都研究院各個開發團隊基本上都有幾位35歲以上的開發人員，多是由於我司的工做和生活的平衡作得相對其餘互聯網公司而言更好一些，因此使得你們看起來顯得年輕吧? 畢竟SAP中國研究院連續得到中國外企裏最佳僱主的榮譽並非沒有緣由的。程序員

上圖來自新聞 - SAP再獲「2017中國傑出僱主」稱號github

還有的年輕同事問我，「你一畢業就待在SAP成都，天天坐在同一個地方寫代碼，一寫就是10年。過去10年，過去五年，去年都如此，連寫代碼的姿式都沒變，不以爲枯燥嗎？" 個人回答是: " 我沒有在同一個地方待着，我最初是在軟件園B6的3樓待着，後來又搬到4樓，而後又搬到3樓，而後搬到E5的8樓。個人寫代碼姿式也不是一成不變，隨着年齡的增加，背愈來愈駝了。"web

說實話，在同一個產品長時間工做，一點點都不以爲枯燥那也不太可能。拿我本身來講，在我工做的第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歲了。