突然有一天，我的老闆用非常低沉的聲音叫我的名字，然後對我說：“Jack，公司的業務已經長時間沒有增長了，未來的路不好走，我們需要採取一些必要的措施才能生存下來，這些情況想必你也非常清楚。實話實說吧，我們近期打算縮減員工隊伍，然後對公司的人員結構進行重組，遺憾的是，你不在我們的計劃之內，非常抱歉。”
當時的我 50 歲，在過去的 20 年裡都效力於這家公司。這份得心應手、激動人心而又“循規蹈矩”的工作讓我的生活平靜、幸福而又“乏味”。
聽完老闆的話，我怒火中燒，緊接著厭惡，隨後是憤怒，最後，強烈的恐懼淹沒了我。我冷靜下來，想要聽他說完。
他繼續說道：“但是”，然後停頓了一會兒，這一會兒對我來說無比漫長，因為我迫切想知道他要說什麼。
“鑑於你是公司的元老級員工，我們不忍心失去你，現在有一個其他的崗位空缺，你可以試一試。我們近期拿下了一個名為 clarus 的項目，這個項目目前缺乏開發人員。如果在接下來的 3 個月裡你能夠提升自己的編程技能，那麼你就可以獲得這次機會。需要注意的是，這個項目非常緊迫、重要且不容有失。選擇權歸你，好好考慮一下吧。”
我上一次寫代碼還要追溯到 15 年前，從那以後我的工作主要是管理和運營。重操舊業對我來說無比艱難。況且我的年齡不小了，學習編程技術並不容易。
我花了一天的時間深思熟慮，然後給了老闆肯定的答覆。
現在 6 個月已經過去了......如今，我成了一名出色的開發者，並且，對於團隊來說，我不可或缺且難以替代。
以下是我的表現……
獨當一面
連自己的命運都不能主宰的人是沒有自由可以享受的。—— 古羅馬斯多葛派著名哲學家愛比克泰德（Epictetus）
“Ben 是 SAP BADI 的專家，我也要成為他那樣的人。” “Tom 做業務測試非常厲害，又快又準，我要努力超過他。” “Susie 非常擅長做 ALV 報告，我也要掌握這項技能。”
以上想法經常在我腦海中盤旋，然而很快就消失得無影無蹤。
我意識到我需要發展自己的強項，如果盲目追尋其他人的成功腳步，那麼我永遠也無法成為專家。這種失敗的盲目追逐只能帶來挫敗感。我需要找到自己擅長的領域並努力成為該領域的專家。
Clarus 項目需要大量不同程度定製化的表格。而表格需要保證正確的對齊形式，其開發工作比較繁瑣，需要開發者有足夠的耐心，因此大多數開發者都對此沒有興趣，不願意做這份差事。於是我自告奮勇承擔了這項開發任務，接下來的三個月裡，我盡心盡力完成了開發任務，表格功能也成了我的專屬技能。
這是一件雙贏的事情，團隊很開心，我也很有成就感。
推陳出新
智慧之人敢於拋棄陳舊的知識。—— 美國科幻文學作家、《圓環世界》作者拉瑞·尼文（Larry Niven）
隨著技術的發展，新技術不斷產生，曾經首屈一指的技術日漸消亡。陳舊的技術不僅毫無用處，有時候甚至還會起反作用。
比如，當我最早編程時，內存覆蓋是一個大問題。由於內存空間有限，因此把整個程序放在內存運行往往是行不通的，於是我需要把程序切分成幾部分然後交替使用內存。基於內存限制的現實情況，那時的程序有著自己特有的設計和編碼風格。
如今，大多數情況內存都完全夠用，內存限制已不再是問題。
但是舊的習慣很難改掉，甚至很難發現。想要推陳出新，首先你得意識到自己正在使用的技術已經過時，然後去學習新的技術。
有時候也需要靈活應對，一些舊的邏輯在某些情況下仍然有用。比如，我曾使用 SAP 腳本，這是一個比較古老的表單開發版本。我沿用了它的表單邏輯，為 Smartforms 替換了新的 IDE，然後在其基礎上增加了一些新功能。
簡單來說，我保留基礎的東西，用新的工具替代了舊的工具。這種方式的過渡變得容易多了。
大膽提問
Indira Gandhi 曾說：“敢於質疑的品質是人類進步的基石。”
回顧一下醫生的工作方式。當你身體感到不舒服時，醫生會問你各種問題：生活習慣、最近吃了什麼、哪兒疼、自己吃了什麼藥，等等。人的身體很複雜，很多因素都可能影響健康。醫生對病人全方位提問，以便找到病因。
對於軟件開發來說，研發人員就是醫生，代碼就是病人。當代碼出現問題時，我需要全方位追蹤，以便找到問題的根源。
我不斷提出各種問題，只要與問題有一絲關係我都會問，這些問題有時甚至是非常愚蠢的。
大量的提問為團隊提供瞭解決問題的新視角，提問最終收到了成效。
正如 Richard Feynman（CSDN 編者注：美國理論物理學家，量子電動力學創始人之一，納米技術之父）說的那樣：“我寧願要無法回答的問題，也不要不能質疑的答案。”
用增量方式編程
孔子曾說：“想要移走一座大山，首先需要搬走一塊石頭。”（編者注：子原話不得而知，若有讀者知曉可給出，幸甚。）
開長途車呢？僅僅把車頭對準一個方向然後轟油門就可以到達目的地嗎？顯然不是！ 在開車過程中你需要不斷打方向盤來變換方向，需要觀察路況，還需要停車來補充食物和燃料。只有這樣，你才能成功達到旅途的終點。
軟件開發也是類似的，尤其是耗時漫長的項目。
不要悶頭寫代碼不管它的對錯。相反，每段代碼都應當保證可以運行，然後再編寫新的代碼。這樣的做法不僅有助於保證代碼的正確性，還有助於在較小的代碼塊上進行全面的單元測試。
你還應該不斷評估代碼的設計思路，一旦想要更改，早期小幅度的調整遠比最後階段的更改更有效。
積極獲取反饋
羅伯特·G·艾倫（Robert Allen）曾說：“失敗不可怕，缺乏反饋造成的失敗才可怕。”
同時包含 abcdef 五個字母的最短的英文單詞是什麼？答案是：反饋（Feedback）。
無論是資深工程師還是初級開發者，反饋信息都是重要的武器。
軟件開發過程中，我們很少遇到需求固定不變的情況，開發人員需要實時瞭解需求然後根據需求編寫代碼。因此積極從同事、客戶、上司那裡獲取反饋變得格外重要。
例如，當我開始創建 SAP 表單時，我會定期與同事和最終用戶溝通，及時獲取反饋。這不僅增長了自己的信心，樹立了我在團隊中的地位，而且我用這種簡單的方式消除了自己對需求的誤解。我很少發現自己需要“重寫”代碼。
經常獲得反饋並將頻率保持為每週或每兩週一次，這使應用程序在開發過程中能夠緊密遵循需求並提升團隊協作的效率。
準確評估項目週期
瑞典外交家和作家達格·哈馬舍爾德（Dag Hammarskjold）曾說：“當你費勁九牛二虎之力到達山巔，你會發現它並沒有你想象的那麼高不可攀。”
我開發第一個表單大概花了 5 個星期，並且包含週末的時間。開發第二個表單用了 3 個星期。開發第 3 個表單則僅用了 10 天。
當你最終完成任務時，記錄完成任務所需的時間。極大可能下你會發現它花費的時間比你預想的時間更長，特別是當你剛剛開始的時候。關鍵是要將實際因素考慮並添加到下一個項目中，以便儘可能接近現實。
你有時會高估，有時會低估，但遲早你會成為一名專家，你會更準確地評估項目所需的時間。
準確估算的能力可以提高你在同行中的地位，客戶也會開始信任你。同時，它會提升你的自信心，讓你做出更多的成績。
實時彙報項目進度
Seth Godin（美國作家、前 .com 網絡公司商業主管）曾說：“人們的恐慌源於對事物缺乏足夠的瞭解。”
人們接手項目時總是習慣承諾按時交付。但實際情況總會遇到一些不可控的因素。當“ 演示 ”會議即將開始時你告訴大家代碼還沒有開發完。想象一下，你在大家心中的形象會是怎樣？
錯過最後期限不僅令人尷尬，而且還給了他人“ 監視 ”你工作的機會。每個人都會多次與你核實項目進度，以確保你不再錯過截止日期。這對任何開發人員都是不利的，無論是像我這樣的新人還是經驗豐富的開發者。
實時讓其他人知情，你可以消除意外，別人瞭解了項目進度就知道什麼時候幫助你，這樣一來你也會感到安心。
總結
生活給了我兩個選擇：要麼努力做一些新的事情獲得重生，要麼陷入永無止境的自憐和無用的泥潭中。我選擇了前者！
正如 Satchel Paige 說的那樣：“關乎年齡，心態重於事實，你不在乎，年齡就不是問題。”
英文：How To Be An Awesome 50-Year-Old Developer
鏈接：https://hackernoon.com/how-to-be-an-awesome-50-year-old-developer-a5b888060cba
譯者：安翔，審校：沭七
閱讀更多 CSDN 的文章
