大概四年前我獲得了電腦科學學位並開啟了軟體工程師的職業生涯。我將在這篇文章中分享一些我這一路過來學習到的經驗教訓。先歸納一下：
不要假設
非技術問題才是最困難的
先思考，再寫程式碼
你要創造的東西比用於創造它的工具更重要
每個角色都同等重要
不要假設
在我開始第一份工作後，我的第一個專案是一項長期執行的專案中一個短期任務。這個專案已經經歷過很多開發週期和很多開發者。它有很大很複雜的程式碼庫，而且整合了很多外部服務。
我的第一個任務是修復一些會間歇性故障的單元測試。要測試的程式碼相對老舊，是一位資深開發者曾經編寫的。因為從 UI 看其功能效果良好，並且 QA 也徹底地測試過它，所以我就假設問題*肯定*和測試本身有關。
我花了近三天時間想要修復本來沒有問題的測試方法。當我向我的團隊領導解釋修復工作耗費如此長時間的原因時，他教給了我重要的第一課。他告訴我說：不要只是因為別人的程式碼看起來像是正確的就假設它確實正確。
這可能是我學到的最重要的教訓，而且這一教訓可應用於很多場景，而不僅是程式碼相關領域。舉些例子：
不要只是因為你叫過某人去做某些事就假設他確實會做。永遠記得要達成明確的一致。你讓某人去檢查某些東西但還未得到答覆？那就去跟進一下。如果某些事情是重要的，那就值得保持跟進。
不要假設別人理解你告訴他們的內容，即使他們說自己確實理解。這個教訓是我的職業生涯進入到幫助指導更多初級開發者時所學到的。我發現我會快速說完指令，然後第二天跟進時卻發現相關的開發者沒什麼進展，即使當時他們說過已經完美地理解了需求。相反，你應該讓那個人複述一遍討論過的內容，這樣你才能確保他們確實理解了。這個經驗不僅適用於指導開發者，也可用於向 BA/QA 解釋等等。
不要假設對方是錯的。我發現開發者在自己的程式碼無效時往往傾向於責備他人。你對你寫的程式碼有保護欲，甚至會達到說服自己相信不可能出錯的程度。如果 QA 告訴你他們遇到了一個問題，他們有理由這麼做。消除他們的疑慮不會給你太多損失，而且比起被拒絕，他們也會更加感激。
非技術問題才是最困難的
在大學裡時，所有的問題都是技術方面的，要解決的問題不過就是想辦法讓程式碼有效工作。但是進入職業生涯後，我發現情況很少再會是這樣了。
對於一個跨多個時區工作的大型團隊而言，確保溝通至關重要。要確保流程有效，要有清楚的文件記錄。要確定提供幫助或指導新團隊成員的方法。為開發過程引入新東西時，要確保平滑過渡。當資料數字著眼於推動當前的議程時，要說服專案管理注重長期的程式碼健康。
這只是你在參與專案時會遇到的一部分事情。在我看來，比起追蹤困擾你的空指標，這些問題可要難多了。
先思考，再寫程式碼
你發現了一個可以改進的流程。你立馬決定將其自動化。你投入了所有的空閒時間開發能完全改變你的團隊的工作方式的東西。
聽起來很熟悉，對吧？包括我在內，開發者都熱愛自動化解決方案。
我的經驗教訓是什麼？不要直接寫程式碼。停下來想想問題，而不是解決方案。和更廣泛的人交談一下，而不只是開發者。首先搞清楚這究竟是一個技術問題還是一個流程問題。然後再尋找解決方案。
當然，使用 Docker 和已寫好的完美指令碼構建一些複雜的解決方案確實很炫酷，而且你可能也能學到很多，但為非技術問題提出技術解決方案可能無助於團隊的長期工作。這可能掩蓋更大的問題。
你要創造的東西比用於創造它的工具更重要
我剛畢業時非常熱愛寫程式碼、學習新語言和框架以及任何涉及到技術元素的東西。
不要誤會，我現在依然熱愛。但是，我後來意識到，只要我們開發者使用的工具能讓我們完成工作，那麼工具究竟是什麼其實不重要。在前端開發中，每隔幾天就會有一種新框架。儘管開發者跟進這些進展很重要，但終端使用者（重要的人）並不在乎工作原理，只要有效就行。
每個角色都同等重要
我已經提到了不要自動假設非開發者是錯誤的的重要性。除那之外，我也學習到構成你團隊的每個成員（BA、QA、專案經理、其他利益相關者等等）都和所有開發者一樣重要。
如果沒有每個角色的努力，專案是不會有成果的；類似地，如果不在各種資源型別之間平等地共享資源，專案也不會有成效。
我還學習到，即使確實是開發者寫出了實際的程式碼，但如果沒有利益相關者，程式碼就沒有價值；而如果不能在質量上保證這些程式碼能完成工作，也不會有利益相關者。
總結
希望你能從這些經驗教訓中學到些東西。你在職業生涯中收穫了哪些有用的經驗，不妨也與我們分享！