相信每位開發者在自己開發的過程中，都會反思一些問題，比如怎樣提高編程能力、如何保持心態不砍產品經理、996 之後怎樣恢復精力……
最近閱讀了兩位開發者的文章，他們分別分享了自己開發生涯中學習到的一些東西，其中一位開發者剛工作 1 年，另一位則有 7 年的開發經驗。
他們都信奉“終身學習”，同時也樂於向他人分享自己的想法，那處於不同階段的這兩位開發者的感想有些什麼不同呢？下邊把二者的文章一起分享出來，希望不管編程了幾年的你都能受到一些啓發。
開發 1 年，我學到了什麼？
作者 Pachev Joseph 是 Agile SDE 公司的一名軟件工程師，根據其在 LinkedIn 上的簡歷，在他撰寫本文時，剛好正式入行「軟件開發」一年。
他在文章中分享了對入行一年來的思考和總結，我們不妨看看有哪些值得學習的地方。
A) 學會傾聽和學習
這不是什麼重大的啓發，只是十分基本的常識。但我注意到許多開發者，包括我自己都存在一個這樣的問題：傾向於一聽到問題就開始考慮如何用最好的方案解決它。更糟糕的是，經常是條件發射般地在聽完問題之前就給出了答案。
另外，我發現自己雖然也有在傾聽，但並不會從聽到的內容中學到任何東西。常見的情況是，在聽的時候我就開始思考該如何迴應，而不是關注問題本身。
對此，我從前輩那裏學到經驗是：聽完再回應。剛開始我並沒有總是這樣做，但日復一日，我在這方面做得越來越好。我學會了傾聽、思考，然後纔回答的方式。
B）限制自己的期望
這裏想表達的是，你所聽到和看到別人正在做的事情不一定是你將要做的事情，也不是你應該做的事情。不要僅因爲你的朋友在使用 Kafka、Kubernetes 等框架，或者使用 IronChefer 進行監控，就意味着你也需要這樣做。
我本人有一系列的業餘項目，同時熱衷於追求新技術。但我發現自己推薦的工具並不是大家都需要的，所以我很樂意有其他人幫助我看到它真正的陷阱。
C）保持好奇心和享受樂趣
個人認爲，我們必須時刻保持好奇心，它是讓我們在這個領域不斷成長的最大動力。所有我們持續學習的知識、深入研究幫助我們解決問題的主題都是出於好奇心的驅使。這也能夠幫助我們保持學習的習慣。
擁有好奇心並同時享受我們所做的事情，兩者自然會齊頭並進。即使在我坐下來在寫這篇文章的時候，我也覺得自己十分幸運 —— 工作就是自己的愛好，並能以此謀生。
D）不要給出確切的日期
這個經驗可以說是血淚之談。除非你是“包工頭”，否則千萬不要迫於壓力之下就提供一個確切的日期。我因此喫過一次大虧，不過正是因爲那次的喫虧，我很早就學會了這個行業的基本求生技能。
國際慣例，如果非要提供一個準確的時間，根據互聯網行業的經驗是將你預計的時間x2。
E）不要用主觀的意見去審查代碼
我覺得自己還算比較友善，不過每當我看到自己不同意的註釋時，我也總會問自己“爲什麼被選中的是我？”。
但後來我意識到不應帶着太主觀的想法去審查代碼，諸如“爲什麼要用這個變量名”的評論以前會很容易就惹惱我，但現在我學會了無視這些。我已經意識到，同樣的表達如果面對面交流會有更好的效果，但用文字表達卻會產生誤會。
所以當我在審查代碼過程中進行評論時，我會提醒自己總會有人對自己的看法持反對意見。所以如果大家都能這樣想，一切自然會更好。更重要的是，我不僅學會了不要把別人的評論放在心上，更認識到大多數開發者並不擅長溝通。
F）我只是一名員工
我總是很容易陷入試圖給別人留下深刻印象的陷阱 —— 天性如此。但事實是，無論你的代碼和職業素養多麼令人印象深刻，你都只是公司的員工。即使你喜歡在工作之外創造軟件，也應該在業餘時間做些事。
剛入行六個月時，我總感覺自己需要證明一些事情，但後來我不再執着於此了。曾經我甚至不敢使用帶薪休假的機會，但是正如每個人都會告訴你的那樣，休息非常重要。
所以不要害怕使用所有這些福利（帶薪休假等）來享受工作和生活。畢竟工作與生活的平衡對我們的心理健康至關重要。
P.s：記錄工作日記
如果我能給你一個小建議，那就是記錄一份工作日記。在工作中寫下你能做的或計劃做的任何事情。這樣就可以：
利用好自己的時間額度
跟蹤自己的進度和決策
開發 7 年，我學到了什麼？
開發者 Tomasz Łakomy 將他 7 年的開發生涯中學習到的一些經驗分享了出來。
Tomasz 講到了以下 6 個要點：
編程中最重要的語言
對於中國開發者來說，這個問題的答案多半是“英語”，然而 Tomasz 卻說：是英語，或者西班牙語、中文、波蘭語，或者其它任何你在工作中與他人交流所用的語言。
It's English.Or Spanish.Or Chinese.Or Polish.Or whatever you use to communicate with other people at work.
作者指出“與人交談比與機器交談更重要”。編程是一項團隊運動，雖然存在極少數案例，個人可以從零開發出很出色的產品，但是在絕大多數情況下，編程工作需要一個團隊。
溝通技巧可以決定項目的成敗，甚至 NASA 也因爲這個問題而困擾。項目想要獲得成功，整體的專業技能比純技術技能更爲重要，舉個例子，如果你聘用了世界上最好的五位數據庫專家，但是他們之間拒絕交流，沒有協同工作，那最後交付給你的可能是 MySQL、Aurora 與 MongoDB 的五個不同實例，那又有什麼意義？
深入瞭解你正在開發什麼？爲什麼開發它？
大多數人在有目標感時會更開心，這也適用於工作。作爲軟件開發人員，你的目標不是用 JavaScript 實現 JIRA，或者用 C# 重寫 Trello，你的目標應該是解決代碼問題。
如果你對正在開發或者維護的系統有深入的瞭解，那麼就可以在純技術之外做出決策。這個功能是必要的嗎？它解決了什麼問題？我們能以其它方式解決這個問題嗎？這個問題的優先級這麼高合理嗎？
這種思路有時被稱爲“業務上下文”，但如果你想做好自己的工作，你不僅應該瞭解這些上下文，還要能夠塑造和影響它。這不是說你必須在組織中擁有某個高級職位才能這麼去做，你至少要先去了解這些內容。
代碼審查
不要背地裏審查別人的代碼，並且公開指出其中的問題，你在初級開發者的代碼 PR 下以不好聽的言論挑出了一些問題，這樣並不能證明你有多厲害，相反，這只是說明你不是一個友善的人。
但是如果真的發現別人實現的功能完全無效，那麼怎麼辦呢？合適的做法是私下去聯繫代碼的編寫者，與他們交流，找出他們爲什麼會以這樣的方式實現該功能。
大多數人都不會想着說要寫出不好的代碼，如果他們的代碼你覺得不行，那可能是他們在處理一些你沒注意到的限制問題；或者他們確實編程能力還不夠強，那這個時候就是你展現實力，幫助他們解決問題的時候了。
有些事情會出錯，做好準備
“任何可能出錯的事最終都會出錯”，墨菲定律很可怕，你要始終假設在設計系統時可能會出現問題。
如果你正在構建登錄表單，需要假設用戶會將整本書複製並粘貼到密碼字段中；如果你正在寫一個 WYSIWYG（所見即所得）窗口，要假設有人會試圖破壞它，並且他們很可能會成功；如果你有一個數據庫，假設它會在某個時候出現故障；如果你還沒有測試從 backup 中恢復數據庫，那麼這就不是一個 backup；如果你正在觀衆面前進行現場演示，需要確保 demo 在線上或者離線等情況下都能正常展示。
不要害怕說“我不知道”
剛開始當程序員的時候，可能你會害怕別人發現你不懂某一個問題，所以別人問你而你真的不懂的時候，你不會直接回答說你不知道，並且會給出一些不能確定的答案，但是本身沒有底氣，所以會害怕別人知道真相後覺得你是個騙子。
但是作爲開發者幾年之後，你可能會覺得如果一個東西你還不知道，那可能它是無關緊要的，或者這是你需要現在去學習的另一項新技術。終身學習不是軟件開發的流行語，它是現實。
保持這樣的心態，這個時候，當別人問了一個你不懂的問題時，你就可以大膽地說：我不知道，我還沒有試過，我先看看，然後回覆你。
分享學習成果
當你從“我不知道”的狀態中學習到某項新技術的時候，這時候可以去與他人分享你的學習成果。比如寫自己的博客、錄製視頻教程、在公司的分享活動中演講，或者只是簡單地把知識點告訴另一個人。
二次教學是考驗你是否真正理解你所學的東西的極其有效的手段，而且一般來說，即使是最資深的專家也可以從初學者那裏學習到新東西，這樣對於你和其他人來說是雙贏。
本文分享自微信公衆號 - IT一刻鐘（it_info）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。