這是看完原文 The Worst Kind of Programmer 後的心得。
這篇文章的作者顯然有類似的經驗，所以在這篇文章當中不難感受到他的偏見。不過我覺得有蠻多地方值得討論與借鏡的，在這邊做個紀錄。
在文章當中，他提到在過去的專案裡有位 Frontend Lead，他很有熱情地設定專案架構，選用 Angular 跟 Nx 和 Rx，後端的技術領導則是在 Spring Boot 框架下再加入各種 library，反正就是用那些很酷很潮的技術。
隨著專案需求增加，這位前端 Lead 繼續調整架構，試圖分離業務邏輯跟技術核心，只讓 Junior 寫比較簡單的需求例如 API 文件跟撰寫測試。
後來這位 Frontend Lead 離職，團隊開始沒辦法維護過於複雜的程式碼跟找了一位專家救火，試圖維持開發的產出。但由於架構的複雜度還是影響了團隊的產出速度。但不管是重構或是重寫成本都相當巨大。
問題在哪？
在我眼中看來這反而是經驗不足的工程師才會做出的行為。（很像過去的自己，先懺悔🙏）
在剛剛提到的例子裡頭，這位 Frontend Lead 很認真，或許又能夠為了他的履歷增添一筆亮眼的紀錄，導入完成後再拍拍屁股走人，然而實際上卻是拖垮整個團隊的開發速度。
所以我一直很認同剛開始就過度設計是萬惡的根源，倒也不是說新的框架都不能用，而是看幾篇文章就貿然引入新框架或函式庫，剛開始覺得沒什麼其實對專案的影響是非常大的。
優秀的 Engineering 過程應該總是尋求簡潔、恰到好處的解法。一個我蠻喜歡的例子是鋼琴的擊弦機制的變化，目前看過解釋最好的 Mark Rober 這部影片中的解釋，動畫非常的容易理解。
為什麼鋼琴的擊弦機制看起來那麼複雜？為什麼不能那一個東西敲在弦上面就好？要怎樣才能做到按住琴鍵時保持音的延續放開才會停？
這些都是從簡單的問題開始一步步進化才變成現在這樣，而不是一剛開始就能找到的答案，一旦去理解為什麼，反而會讚嘆原來整個機制都是剛剛好的設計。同理搬過來軟體開發也一樣，不是一開始就導入各種框架，而是針對目前的問題一步步找尋最佳解。
文章後面有些地方我就不是那麼認同，例如他說解決抽象問題的能力、能長時間工作、對軟體開發有熱情，這些我覺得都是很好的特質。當然長時間工作這件事隨著人生階段也會產生變化，想要把重心放在別的事情上。
另外一個很常被忽略的指標是程式碼是否「容易修改、刪除」。
當我在動相關的程式碼片段時，是否可以很有信心地刪除某個地方而不會造成連環效應，或是設計時可以很容易替換掉實作，另外一點則是當其他人也想要修改程式碼的時候，他們是否可以快速理解後按照同樣的方式修改。從這點來看我很喜歡 adapter 模式，介面決定好之後，後面的實作怎麼做都可以。
有些人在 Code Review 上非常嚴格，常常基於個人的觀點於喜好做批評而非針對整體功能的設計與讓程式碼變得更易讀的建議。
更不用說在格式上面做文章了，如果發現團隊當中大部分的爭論都是在格式上的話，那麼是該考慮檢討 ESLint 或 Prettier 的設定是否恰當了。
溝通
我覺得在團隊裡，在做任何重大決策的時候，至少應該先跟團隊討論過。
不一定要每個人都同意，但也不需要把團隊的其他人都當作笨蛋，覺得自己的解法最厲害。在正常的情況下，大家都是想要讓產品變得更好，開發變得更順暢。
這邊有兩件事要注意：
- 有時候會因為團隊成員已經習慣現在的寫法而下意識反對新的提案，這時候可以去交待背景跟自己為什麼會認為新的提案比較好
- 身為團隊比較資深的成員，看到新提案的時候可以提出更多脈絡或歷史資料給對方參考
在貝佐斯跟 Lex Fridman 的 Podcast 當中有提到 — disagree and commit。
我愛死這種想法了。
不認同但全力支持。為了避免最後只有各方不斷提意見的口水戰，一旦決定做法，就算不認同也會全力支持，至少專案是有在前進而不是虛耗，這是我覺得很棒的態度。
尤其是當團隊都是聰明人時，通常會不同意的地方應該只有一小部分而已。（當然，前提是要有一個菁英團隊）
Disagree and commit is a really important principle that saves a lot of arguing. There will be disagreements in any endeavor in life where you have teammates. In society, and inside companies, we have a bunch of mechanisms we use to resolve disputes. And a lot of them are really bad. An example of a really bad way of coming to an agreement is compromise.
這邊貝佐斯有提到最糟糕的方式是妥協，各方折衷的結果就是生出縫合怪。
這部分我也感受良多，有時候職權不夠或是聲望還沒有建立起來的時候，的確是只能被迫接受妥協，也讓我思考蠻多軟體開發都是處在一個需求過來，評估之後再由開發團隊實作的狀態，反而開發團隊比較少參與到整個構思的過程。
也就造成了明明技術還不錯，但好像自己要打造產品時卻好像做不出什麼東西來，或是自己做的東西不是使用者想要的，也是自己最近直面的課題之一。不知道大家有什麼好方法？
