我在第一份工作時被炒了魷魚，因為一個寫得很糟的查詢把資料庫伺服器弄掛了，還被 FAANG 拒絕錄取。這些事全都發生在過去 10 年裡。
但一路走來，我在寫程式這件事上學到了一兩個教訓：
1. 預估只是猜測。
問題在於：你的猜測，和其他人的猜測對不上。
2. 展示進度比真的把事情做完更重要。
你猜自己能在 4 天內完成一項任務嗎？不不不。
你最好把它拆成更小的專案，讓大家看到進度。
3. 概念驗證比沒人會讀的長篇文件更好。
你上一次讀超過 2、3 頁的文件是什麼時候？
你最好快速做一個簡陋的 Pull Request，來展示一個想法或原型。"有可執行的程式碼，勝過文件。"
4. 寫完程式不代表工作就結束了。
寫完程式之後，還有部署、測試、使用者採用、客戶支援，以及後續跟進。
5. 職位越資深，越不是在寫程式，而是在開會。
你加入軟體工程，是因為你喜歡寫程式嗎？忘了這件事吧。
你會把更多時間花在會議上：
- 一對一會議，
- 每日站會，
- 回顧會，
- 迭代規劃，
- 對齊會議，
- 腦力激盪會議，
- 撲克牌估點會議，
- 還有和另一個團隊某個傢伙花幾分鐘溝通，他需要碰你一年前寫的程式碼，而你現在已經不記得了。
還沒完……
在最理想的一天，你大概只有 1 到 2 小時能不受干擾地寫程式。
6. 當你和舊系統應用程式共事時，你會開始愛上測試。
不管叫它單元測試、整合測試、端對端測試、TDD、BDD，還是任何 DD。
你最好有任何一種方式，讓你在把程式部署出去之前，就知道自己把東西弄壞了。
7. 沒人要求你，就不要開始大規模重構。
這就是我所說的 未經請求的大規模重構。
不是把重構當成你任務的一部分，並且尊重你目前的預估時間（見第 1 點）；就是把它正式納入你的迭代規劃。中間沒有什麼折衷空間。
8. 不要把時間浪費在關於工具或技術的無謂爭論上。
—「Entity Framework 是最好的。」
—「不，它慢到讓人痛苦。」
—「不不不，預存程序才是最好的」
唉啊啊啊！
工具就只是工具。
這也是為什麼我們這些寫程式的人，常被認為很愛爭辯、脾氣又差。
還有，拜託別再談什麼整潔程式碼和最佳實踐了。那是我已經改變想法的主題。
9. 永遠把程式碼風格和最佳實踐自動化。
不要叫人類去做機器的工作。
程式碼風格非常適合交給機器來處理。
10. 專案失敗是因為溝通問題。
這跟我聽過關於婚姻的說法是一樣的。
在我以前的一份工作裡，我參與的是 3 個月或 6 個月的專案。
我們用了最炫、最亮眼的工具和框架。
但有些專案最後還是偏離了軌道。
唯一變動的因素是什麼？
我們的溝通方式：
沒有及時溝通期待、專案目標與範圍、行動計畫，以及技術問題。
11. 每一個技術問題，本質上都是溝通問題。
這是第 10 點的推論。
在我以前的一份工作裡，我剛接觸 ASP.NET Core；當我想測試我的程式碼時，我改了設定檔裡的一個連線字串，結果把另一個環境的資料庫刪掉了。喔不！
我在錯誤的環境裡用了錯誤的設定檔。
我沒有去問，沒有人告訴我，而且程式碼裡也沒有任何限制或保護機制。
這是個溝通問題。
12. 解決你今天真正遇到的問題。
不管是過早最佳化，還是單純懶惰，都不要去解決或最佳化你還沒遇到的問題。避免撰寫那種「以防萬一」的程式碼。
_如果這些話讓你很有共鳴，可以看看 Street‑Smart Coding，這是一份我希望自己剛開始寫程式時就能擁有的路線圖，裡面有 30 個實用教訓。_
原文出處：https://dev.to/canro91/12-hard-truths-about-coding-i-learned-the-hard-way-after-10-years-124j
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
