從 14 歲起，我就開始在父母的臥室裡寫代碼。當時，通過非常慢的網絡，我閱讀任何能夠獲得的東西。20 歲時，作為一名 Web 開發人員，我籤了人生中的第一份勞動合同，當時學的是 PHP 和 JavaScript。
在這個領域，我花了 18 年時間，才發現編程只是職業的一小部分。即使是空閒時間出於興趣，我也不會停止編碼，但工作中還有很多其它事情。有些事情，開發者往往很晚才能領悟到，這也是為什麼我想和大家分享我的經歷，以及我覺得很重要的 9 個經驗教訓。
開發者通常很自負。這是事實。
為什麼呢？我認為，任何認真對待自己職業的人都會認為自己有點兒像藝術家。我們雖然不會在數百萬人面前唱歌或者作畫，但我們有時候在以一種非常優雅高效的方式編寫代碼、解決非常複雜的問題，我們同樣為自己的工作感到自豪。
開發者和數學家一樣，解決問題的方式都有點兒像藝術家。
正因如此，我們很維護自己的代碼——就像熊媽媽照顧她的後代那樣。親手寫下這些代碼的我們，無法忍受別人對他指指點點。
但這對任何人都沒有幫助。我們熱愛自己的工作，但更重要的是我們正在解決問題。通過與其他人討論我們的想法和方案，可能會出現更好的替代方案。這沒有什麼不對的。事實上，合作通常會產生最佳解決方案。
我見過各種各樣自負的開發者，但沒有見過哪種自負對開發者會有所幫助。
因此我的建議是：當你開始作為一名開發者工作時，請把你的自負拋掉，多聽聽其他人對你工作的看法。學會接受這樣一個事實：更好的想法可能來自你的頭腦之外，它們只會幫你提高自己的技能。只有傾聽反饋，你才能贏。
如果你只懂 JavaScript，所有的問題都會像釘子一樣。不要再稱自己是一名 Java 開發者或 JavaScript 開發者。
由於某些語言的特性或語法，你可能會偏愛一些語言，這很正常。然而，如果你能學點別的東西，就會受益匪淺。學習新語言，尤其與你日常工作所用的範式不同的語言，會幫助你打開思路，發現解決問題的不同辦法。
這一點我怎麼強調也不過分：學習多種語言並使用一段時間，你會從中受益。
我幾年前讀過一本書《七周七語言》，展示了各種可用的選項，這讓我思路大開。很多選擇是我從來沒有想到過的，因為我太專注於自己的日常任務和日常工具，從來沒有停下來看看其它東西。
https://www.amazon.com/-/es/Bruce-Tate/dp/193435659X/
我們是開發者，知道如何通過代碼來解決問題，但不要把自己放到一個盒子中，你會被那個盒子的大小所限制。看看那個盒子外面的東西，跳出那個盒子思考，試試其它選項、其它語言、其它解決問題的方法。即使只是一會兒，你也會帶著新的想法和更大的心態做出更好的抉擇。
有時候，開發新手認為他們需要把所有事情都記在心裡，因此當他們意識到自己開始忘記如何寫一個簡單的 for 語句時，就會感到很糟糕。
這不僅是正常的，而且我認為這也是健康的。
有太多東西需要記憶了，但我們其實不需要記憶，我們只需要擁抱這樣一個事實：網際網路是另一個有力的工具。就像我們需要 IDE 一樣，我們需要網際網路來尋找答案。
我們都這樣做，如果你一開始就感覺不好，就不要在這種感覺上浪費時間。只需要尋找你的答案並解決你的問題。
這樣想一想：每一種語言都有一種類似但又稍有不同的觀察者（Observer）模式的實現方式。你認為什麼更現實？理解觀察者模式有什麼好處以及它能解決什麼問題，還是記住你所使用的每一種語言如何實現它？
如果你知道它能解決你的問題，那麼你就真的解決了你的問題。剩下的只是搜索實現它的最佳方法。
其它搜索也是一樣。只專注於我們職業中重要的解決問題的方面，讓谷歌幫你慢慢回憶。這才是正確的方式。
或者說，「你應該終身學習」，這完全取決於你自己是否要跟上行業的最新發展。如果你想要保持相關性，那麼你就必須一直學習。
技術在發展，語言在變化，這都很正常。誠然，有些生態系統比其它生態系統變化得更快，跟上他們的步伐似乎是一項艱巨的任務。但是，記住你只是一個人，不可能無所不知，只需專注於重要的事情。如果你必須學會一件事情，那麼我的建議是學會如何學習。
這聽起來很傻，但這可能是一名開發人員需要的首要技能。我們必須在快速學習新技能方面表現得更好。否則，你將陷入被標記為「過時」的風險。
同時，這也是本文提到的其它經驗發揮作用的地方。變化、改變、新的挑戰、沒有自負——所有這些都會幫助你學習並拓展技能範圍。你做的越多，效果就會越好。最終，你會發現所有的語言都是類似的。你將開始看到它們公共的根本，你將能夠用其中任何一種語言工作。你所要做的就是閱讀一些關鍵的東西。
你的整個職業生涯都要學習：
新語言
新（老）編程範式
新工作方法
解決問題的新方法
與團隊互動的新方法
檢查和測試代碼的新方法
如果你還沒有準備好永遠當一名學生，那你需要考慮下這個職業是否適合你。請注意，我不是說「立刻辭職」，而是考慮下是否願意開放思維來持續學習。
這個問題我說過很多次，但是作為開發者，我們傾向於認為自己的代碼在發布之前需要是完美的。雖然這並沒有什麼不對，但也可能是一個潛在的問題。
早期優化是一個問題，因為你可能在某件可能並不需要優化的事上花費大量時間，而且在某些情況下執行優化時，你會做出破壞功能的假設。
所以，把注意力集中在需要做的工作和你正在嘗試解決的問題上，一旦問題修復，立馬測試、迭代結果，看看團隊對你的解決方案有什麼想法——即使你已經看到了改進的方法。如果你需要花費兩天以上的時間來讓它完美，但它現在就可以投入生產，很有可能現在就應該投入生產。
歸根結底，你是在解決問題。解決問題越快，對你的用戶就越好。
跟上面提到的觀點一樣，不要陷入早期優化的黑洞。
即使你認為你可以快速優化，但一旦你開始做，你就會發現時間膨脹效應是真的。
作為軟體開發人員的首要任務是寫一個功能或修復一個 bug 來讓它起作用——無論代碼看起來多醜或者你的方案可能多麼低效。如果它起作用了，你就證明了它是可行的。這就成功了一半。
第二步是優化它。這是可選的一步。一些人容易忘記的細節，你可以用來優化代碼的時間取決於很多變量，這些變量有時候不受你的控制。因此，集中精力讓它起作用，然後再看看你是否真有時間來優化它。
早期優化意味著要邊寫代碼邊優化，這是一種危險的方式，因為優化時，我們都是在對執行時間、數據要求、內存需求以及其它我們尚未看到的因素進行假設，任何這樣的假設都可能是錯誤的，最終會在你的邏輯中引入 bug。
想想 TDD 工作流：
步驟 2 是必需的。你首先需要考慮通過測試，也就是說讓功能起作用。測試不關心你使用的算法或者你是否使用了三層嵌套的 if 語句。稍後才會做那些，可能是代碼評審過程中的一部分。
7 項目最後的 10% 往往要花費 90% 的時間如果你一個人獨自工作，這一點尤其重要，但是團隊也會有這種細節計算失誤的問題。
任何一個做完項目的人都會告訴你同樣的事情（這不僅僅適用於我們行業）：你一開始會略過很多細節，最後才不得不考慮它們。
這很正常。我們都傾向於一開始專注於重大的功能，將比較小的細節或已知的 bug 留到最後。但是它們仍然需要解決，這就是額外 90% 的工作。精細的工作比較花時間。你需要測試、修復、重新測試、寫文檔、執行用戶培訓、展示最終方案等等。
當然，這取決於你的環境、客戶以及很多其它因素，但總會有一些東西。所以記住：當你認為你已經寫完代碼的時候，你很可能忘記了一些東西。
編碼是關於抽象的行為。通過抽象通用邏輯，我們可以在其它地方復用它，但是一開始的時候，我們有時會注意不到抽象的重要性。
這是我個人的經驗法則：如果我在兩個地方寫了相同的代碼，那麼就將它們放到一個函數中（或者一個方法，一個模塊等等... 你懂的）。
即使數字二對你來說很低，但是要考慮到將來你可能在其它地方使用抽象後的代碼。而且通過把它放到一個常用的地方，你現在就可以使用它了。
抽象和規模有關。一段抽象的邏輯可以用很少的精力就被復用很多次，而到處複製粘貼代碼雖然很容易，但用的越多需要的精力就越多。想想，如果你因為一個 bug 不得不改變一段邏輯，而它在你的項目中被重複了 5 次，會發生什麼？你在修復這個 bug 時，會有 5 次機會犯錯。
同樣的邏輯也適用於你的日常任務。如果你發現自己做某件事一次以上，那麼它可能就可以用某種方式自動化。這是效率的關鍵，因此不要僅僅在代碼中尋找重複模式，在你的動作中也可以尋找重複模式。如果你能自動化完成一項每天需要 10 分鐘的任務，你一個月就能節省 5 個小時。
有人說，如果你想要成為一名成功的開發人員，你需要創建副業項目。我並不認同這一點。我個人認識很多優秀的開發者，他們只在朝九晚五工作時寫代碼。
老實說，我很欽佩他們。他們能夠在做好工作的同時，享受他們的空閒時間做其它事情。這絕對沒有什麼問題。
然而，有時候你需要一些額外的練習。有時候你覺得自己落後於其它同事。而這時，副業項目就會有所幫助。
我不是說構建一個新項目，讓數以百萬計的人使用，或者對產業進行革命性改變，當然如果你喜歡的話，就去做。但是我討論的是拷貝其他人的項目，以便從中學習。我說的是通過解決 bug 或者增加額外功能來向其他人的項目做貢獻。
你可以用副業項目來體驗你不經常看到的地方。如果你每天寫 8 小時的單元測試，也許可以考慮從頭創建一些東西並且開發一些功能。如果你厭倦了獨自工作，可以考慮為現有的項目做貢獻，體驗一下如何與其他人協調工作。
你可以使用副業項目來強化自己的薄弱環節，從而幫助你提高自己的技能。但同樣，不要為了被認為是一名嚴肅的開發人員，而認為你需要為他們工作或者擁有一個綠色的 GitHub 活動圖。那太傻了。
這是我作為一名開發者在過去 18 年中學到的最難的 9 個經驗教訓，希望通過我的分享，能對你的新（或者已經從事的）職業有所啟示。
原文連結：
https://medium.com/better-programming/9-hard-lessons-i-struggled-to-learn-during-my-18-years-as-a-software-developer-14f28512f647