程式設計這個行業裡，經驗是最難以獲取的東西，而且也不容易教授。一般來說，程式設計師都是邊做邊學，如果你想學點什麼新技術，最好的辦法就是拿它來做專案。在這個實踐的過程中，犯錯誤是你必須要欣然接受的事情，因為你從錯誤中學到的東西會很多。這就是積累經驗的必經之路。
怎麼看出來一個程式設計師經驗不足呢？可以從這四個跡象看出來。
非結構化的程式碼什麼叫“非結構化的程式碼”呢？一個比較具體的例子是臃腫而且複雜的函式，試想一下一個函式的長度和一篇論文一樣長（幾百幾千行），執行的不同功能有好幾個（比如說5個）。
為什麼這種巨無霸函式會被寫出來呢，驅動力主要是“儘快讓程式工作”。而驅動程式設計師不管不顧地以實現功能為目的編寫程式碼的，一般是所在的團隊想盡快出一個可工作的版本。事實上，實現功能在程式設計師的工作優先順序當中處於中間偏後的位置。重中之重其實是維護程式碼的“可維護性（maintainable）”。比如說這種巨無霸函式的可維護性就非常差，可測試性和可讀性都很低，非但團隊的其他程式設計師很難讀懂，可能過幾天之後你自己也看不懂。這種不可維護的程式碼，在重構（Refactoring）的時候就是攔路虎，幾乎只能重寫，帶來巨大的額外工作量。當新手程式設計師意識到這一點之後，寫程式碼的風格會隨之轉變，以可維護、易讀懂、可測試為指導準則。實現功能只是程式碼質量的一小部分，沒有經過深思熟慮的程式碼會嚴重降低程式碼質量。如果沒有遵守單一職責原則（SRP）寫出一些低內聚的程式碼，當軟體進入運維階段，可能會麻煩不斷，同時也降低了使用者體驗度。
亂槍打鳥式的除錯（Debugging）新手程式設計師在除錯程式碼的時候，有時候會隨機地修改程式碼的某個部分，在對實際問題並沒有進行深入瞭解的情況下希望解決問題。實際上這種亂槍打鳥式的除錯在大部分情況下是無法解決問題的，壞就壞在有時候可以。而且，在這個過程中可能已經導致了更多的問題和錯誤。實際上，在解決問題之前應該做的事情是收集儘可能多的相關資訊，對問題進行分析，確定你的方案可以在解決問題的同時不導致更多問題。第一件事情是找出重演的方法，找出觸發的引數。然後你可以開啟日誌（如果有的話），這是找到病灶的快捷方法。當你搞清楚了出錯的原因，如果想做得更好，還應該編寫相應的測試用例，這樣一來當你把bug解決之後，測試的覆蓋度也相應的得到擴充套件。
過度關注於技術面新手程式設計師需要花費大量的時間才能掌握一種技術棧，這當然是沒有錯的。現在的技術棧越來越龐大，不管是Java還是.Net，或者是Node.Js（React/Vue/Angular等），想要掌握一門都需要花費很長時間來學習。不過，不應該只關注技術面。
僱主給你一份工作的目的，是讓你為企業創造價值，這一點你應該一直謹記在心。過度鑽研技術如果導致在與工作無關的事情上花費過多的時間，這樣一來就違背了為企業創造價值的指導方針。成為程式設計師不能僅僅對技術感興趣，商業面的知識才是證明你價值的因素。
有點與眾不同在團隊工作當中，那個偶爾或者常常特立獨行的程式設計師很可能是一個新手。缺乏經驗的開發人員會傾向於用自己的工作方式來工作（可能是自己的舒適圈），而不是和團隊的其他成員保持一致。
很多時候新手下意識地去用自己的方法來寫程式碼，因為無法識別某些特定的模式（Pattern，比如說大名鼎鼎的GoF23）。
為了儘快地融入團隊，你可以檢視版本庫裡面其他成員建立的pull請求中的程式碼。有時候別的團隊成員解決的任務（task）和你的類似，這樣一來你透過閱讀他的程式碼可以獲得解決自己任務的靈感。當然，如果你讀不懂，也可以去找TA請教。
參考：https://levelup.gitconnected.com/4-signs-of-an-inexperienced-developer-851966fdc6b1