第一種方法：暴力解。
假如軟體工程師是楓之谷裡的職業，我就是把力量跟敏捷點滿的那傢伙。
「遇到一面牆？只要我撞得夠用力，夠快，那面牆總會倒下來的。」
這種心態在我做為 IC3 - IC4 的前三年非常有用，也幫助我快速升職了兩次。反正在一個做產品的團隊裡，我們也不大會遇到什麼太硬的牆。一旦決定要做什麼之後，剩下的寫 code 反而會是最簡單的工作。
於是，在花了幾年混熟了我們團隊的 codebase 之後，我解鎖了第一種把十週長的專案用五週搞定的方法。
也就是，超有效率地寫 code。
然而，在最近一個專案計畫的會議裡面，我看見了一個資深工程師使用另一種方法。
第二種方法。
很簡單，只要說：「不，為什麼要做這個？」
他在會議裡質疑設計師與 PM 提出的不同功能——當然，是很有道理與語氣尊重地說。在這個會議之前，我就已經先讀過議程，而且大概把設計師與 PM 提出的所有功能都評估過。我知道，整個專案大概需要十週去做。
但是，他完全打亂了我準備好的這些資料。
也打開了我的視野。
他快刀斬亂麻地在會議裡說服所有人某些功能並不重要，不做既不會影響使用者體驗，也不會影響我們最後想要得到的 A/B 實驗數據。甚至，做了這些看似有用，實則沒用的功能，還會讓團隊需要去承擔更多寫出 bug、與未來還要維護的風險與開銷。
半個小時過後，代辦事項剩下一半。
也就自然而然地只需要原本一半的時間去做。
所以，雖然這個結論聽起來直觀得有點白癡——但，把專案用一半的時間就搞定的第二種方法，就是只去做一半的事情。
有用的那一半。
透過說「不」，或者說，真正地做為團隊的腦袋，帶有批判性思維地說不，替團隊去發現有一半的工作並不重要，並不需要去做，他簡簡單單就讓我們只要用一半的時間，就能做出最核心的使用者體驗，並且取得實驗結果去儘早更迭專案。
而我則大開眼界，找到一條我原本沒想到的成長道路。
就算我能夠比別人快的寫 code，但要是我寫出來的 code 是沒用的，那也是白搭的。
現在仔細想想，過去四年我確實寫出了不少最後還是要刪掉的 code。笑死。
