我改變的事項包括：
我之前爭論不休的一些東西，我現在開始確信：
- 當你在一個團隊中與各種水平的人一起工作時，強類型語言會更好
- 創業公司事實上更有利於新手
- 衝刺回顧只要能用於實際的課程改正（比如“天哪，太差勁了”），還是有它自己的位置的，而不是某些可怕的“agile” “scrum master” 會浪費每個人的時間
- 軟件架構的影響更大。對好的抽獎的糟糕的實現並不會對代碼庫造成任何損壞。一個不好的抽象或者缺失的層會導致所有東西腐爛。
- java語言不是那麼糟糕
- 聰明的代碼通常不是好代碼，清晰度比其他所有問題都重要。
- 錯誤代碼可以用任何範式編寫
- 所謂的最佳實踐是上下文相關的，不能廣泛應用。盲目跟風會使你成爲白癡。
- 當你不需要構建可伸縮系統的時候，會讓你變成一個差工程師
- 靜態分析很有用
- DRY的目的是避免特定的問題，而不是最終的目標
- 通常來說，RDBMS > NoSql
- 函數編程是另一種工具，而不是萬能藥
我一路走來的意見
- YAGNI, SOLID, DRY. 按照這個順序來
- 鉛筆和紙是最好的編程工具，很少被使用
- 用純粹性換取實用性通常是個好選擇
- 使用更多的技術很少是個好選擇
- 直接對接客戶總是可以在更短的時間內以更高的準確性揭示更多有關問題的信息
- “可伸縮”一詞在軟件工程師心中具有神祕而愚蠢的力量。它的純粹性話語可以將他們鞭打成墮落的狂熱，使用這個詞已經證明嚴厲的行動是合理的。
- 儘管被稱爲“工程師”，但大多數決策都是“貨物崇拜”，沒有任何背景分析、數據或數字
- 90%（也許是93%）的項目經理，可能會由於沒有影響或者效率上的收益在明天消失調
- 進行100次面試後，面試徹底中斷了。我也不知道如何使它更好。
未改變的看法
- 強調代碼風格，棉絨規則或者其他細節的人都是瘋子
- 代碼覆蓋率和代碼質量一點關係沒有
- 整體結構在大多數情況下都非常好
- TDD主義者是最糟糕的，他們虛弱的小頭腦無法處理的存在的不同的工作流程。
我們將在第10年看到其中哪些會發生翻轉或更改。
原文：
Software development topics I've changed my mind on after 6 years in the industry
譯註:
- 靜態分析：應該主要指代碼審查、架構評審之類的
- YAGNI：You Ain’t Gonna Need It，軟件開發中的適可而止原則
- SOLID：設計模式的六大原則，單一職責原則（Single Responsibility Principle），開閉原則（Open Closed Principle），里氏替換原則（Liskov Substitution Principle），迪米特法則（Law of Demeter），接口隔離原則（Interface Segregation Principle），依賴倒置原則（Dependence Inversion Principle）。