2006年成立的SAP成都研究院，位于天府軟體園B區。如今，因為研究院發展的不斷壯大, 已經搬遷到天府軟體園E區了，是以，發生在圖檔building各種充滿悲歡離合的故事，已經成為一部分小夥伴腦海中難以磨滅的回憶，永遠消逝于曆史的長河之中。
SAP成都研究院有很多剛從大學畢業不久的年輕小夥伴加入。一起聊天時，有小夥伴悄悄向我打聽，”咱們公司的開發人員們咋看起來都是年輕人？35歲以上的開發人員去哪兒了？難道程式員真是吃青春飯的？”
這些同學想的比較遠，值得贊一個，看來TA已經在思考自己未來的職業發展之路了。據我所知，SAP成都研究院各個開發團隊基本上都有幾位35歲以上的開發人員，可能是因為我司的工作和生活的平衡做得相對其他網際網路公司而言更好一些，是以使得大家看起來顯得年輕吧? 畢竟SAP中國研究院連續獲得中國外企裡最佳雇主的榮譽并不是沒有原因的。
還有的年輕同僚問我，“你一畢業就待在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上寫作，在公衆平台上寫部落格，或者寫微信公衆号文章。
年輕同僚關于技術分享的一些顧慮/問題：
Jerry的建議：
國小我們學寫記叙文時，國文老師會教我們一些套路。寫技術文章也是如此，最簡單的套路：提出問題-分析問題-解決問題。我們日常的開發工作中不可能不會遇到問題吧，這些問題就成為技術分享的來源, 不需要去空想。
Jerry的建議:
首先要明确，個人的技術分享，最主要的目的是梳理，打造和完善自己的知識體系，至于别人會不會看了受益，這是次要問題。我自己的親身體會，在寫SAP community部落格時，我經常遇到寫着寫着就寫不下去，或者是發現自己無法用語言準确表述自己腦子裡的想法。這種現象就說明我對我正在寫的這個知識點實際上還未透徹了解，會迫使我回過頭去做進一步深入研究。研究->寫作->研究的這種疊代和不斷重複，就是我逐漸形成自己解決問題的套路和方法論的過程。
現在很多大神都在自己的微信公衆号上寫技術文章，為什麼我們關注了很多大神，拜讀了他們很多文章，過了半個月再回憶之前讀過的那些文章，發覺自己記不清文章的内容了。我們雖然讀了很多技術文章，但是反而覺得和大神們的距離原來越遠?
上圖的科學研究結果表明，單純的被動學習就其記憶留存率來說是最低效的，而主動學習表面上看會花費更多的時間，而成本效益卻是最高的。我個人最喜歡的主動學習方式就是把我新學到的東西寫成文字，”一次勞神，終生受益”。就像程式設計開發裡的庫函數一樣，寫好之後可以到處用。
退一萬步說，即使您的文章真的沒人看，它們至少是您在雲端的一份個人技術成長日志。每隔一段時間，比如一個季度，半年，一年，當你回顧你以前寫過的這些日志，您能清晰地判斷出這段時間内您的技術是有精進，還是在原地踏步。
我們來做個小測驗：您能準确回憶起您過去一年内，每個月都做了哪些具體的開發任務？反正我是無法用腦子回憶起來。但是因為我在SAP community上分享了很多我每天工作中新學到的東西，或者是解決的一個難題，再加上我用CDS view做了一個統計這些分享的小工具，是以我能在1秒鐘内得到各種次元的資訊。
比如我每年總共分享的文章數
每個月分享的文章數從高到底排序
第三多的月份是去年10月，因為那段時間全花在幫助一個國内C4C客戶的上線支援上了，寫的文章全是上線過程中遇到的具體問題。
再比如我想回憶5年前的11月份我幹了哪些事情？
從文章清單我就能立即回憶起那段日子我正忙着和Poseidon一起，幫助中央電視台CRM項目組共同處理影響項目上線的一些緊急問題。
3. 害怕自己寫的文章裡包含錯誤，被别人指責
這個沒什麼擔心的，是人都會犯錯誤，有人指出錯誤，可以督促自己回過頭進一步研究驗證。如果發現确實是自己錯誤，誠實地承認并且改正就行。如果依然覺得自己是對的，耐心和别人讨論 - 您應該感謝網絡上花費自己時間仔細閱讀了您的文章，并且提出寶貴意見的這些熱心人。
這裡的自動化指的是: 如果您每天的日常工作中包含一些瑣碎的，重複性的，并且完成這些工作需要遵循的規則是能夠用代碼清晰描述的，那麼盡可能也讓代碼來完成它們，把節省下的時間投入到真正具有創造性的工作中去。
我的一些自動化例子:
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開發生涯裡寫過大量這種自動化工具，多得我自己都數不清了。
為了友善使用這些工具，我又寫了一些管理這些工具的工具，友善我快速找到我想用的工具：
<a href="https://blogs.sap.com/2017/03/25/some-small-abap-tools-i-write-to-improve-daily-work-efficiency-or-just-for-fun/">Some small ABAP tools I write to improve daily work efficiency or just for fun</a>
目的如上面說的，我痛恨體力勞動，我要用代碼來完成它們。
2. web應用調試的自動化。
如果是背景代碼的bug，我經常遇到的情況是，每次我得在前台做N次的點選，跳轉，才能觸發我背景的斷點，而我處理的背景錯誤沒有10次8次的調試根本無法定位問題。每次斷點觸發之前的重複操作讓我忍無可忍，是以我通常會自己寫一個小程式模拟前台的操作，每次執行這個小程式，1秒鐘即可觸發斷點。
我把這種專門為了友善調試而開發的小程式稱為腳手架。
(注: 這篇部落格的釋出時間讓我回憶起那不堪回首的調試經曆，2014年4月30日調試了整整一天，花費了8個小時最後才找到問題根源。)
如果是前台js代碼的bug, 但是必須依賴于背景某些特定的資料才能重制，而生成這些資料又需要在前台做很多複雜的操作，這導緻每觸發一次前台的斷點要花很多時間。為了避免這種觸發斷點前不必要的等待，UI5裡面提供了成熟的解決方案：直接把能引起前台出錯的背景資料儲存下來作為MOCK DATA, 然後使用UI5的MOCK SERVER把前台發向背景的請求攔截并重定向到MOCK SERVER.
總結
啰嗦了這麼多，對于年輕的開發同僚們我的三點個人建議:
1. 當您發現您在目前工作崗位上已經進入成長瓶頸期，現在的工作内容已經成為您的舒适區時，和您的管理者交流，确認您的感覺是否真的和事實一緻。如果屬實，一起探讨有沒有可能去做一些更有挑戰性，能讓您更快成長的任務。
2. 養成知識積累并分享出來的習慣。
3. 将您工作中一切瑣碎，重複，讓您抓狂的事情自動化起來。
最後，回到文章題目的問題：SAP成都研究院35歲以上的開發人員都到哪兒去了？
我的回答：就在您的身邊。我迅速在腦子裡過了一遍，成都SAP研究院每個靈活開發小組都有至少兩到三位35歲以上的資深開發人員，别說35歲，40多歲的都有。咱們同僚在公司内部都從不叫他們的英文名字，而直接叫某某老師。
SAP成都研究院開發人員裡最傑出的代表，當然是以人工智能和機器學習聞名于整個西南地區的進階資料科學家Ding Orlando。據我所知我們這位科學家今年也超過三十五歲了，依然是SAP成都研究院開發領域内的旗幟人物。當然我是不會把他的微信号洩露出來的，不然被其他公司挖走，Poseidon會把我掐死。
另一部分和我同一年進SAP成都研究院的小夥伴們，時光荏苒，現在大都已經超過35歲了。
有的出去自己開公司，早已财務自由了;
有的去其他公司當CEO/CTO/CIO了;
有的改行了，成為金融／政界精英;
有的移民其他國家，在當地繼續從事SAP行業;
剩下的一部分選擇了繼續留在SAP成都研究院 。
這剩下的一部分有的轉型成了管理者，有的成為了産品經理，有的成為了架構師，還有的就像我這樣, 還在繼續做開發。
接下來的公衆号文章, 會有SAP成都研究院其他資深同僚分享自己的故事：如何從開發人員成功轉型成一名成功的XXXX。 對這一職業生涯發展感興趣的年輕同僚們敬請期待。
附錄: 一些網際網路上的文章
要擷取更多Jerry的原創技術文章，請關注公衆号”汪子熙”或者掃描下面二維碼: