印象中「十倍工程師」大約是在我出大學到剛出社會這段期間蠻熱門的一個關鍵字，通常用來指能夠發揮一般工程師十倍生產力的稀有工程師。
假設一天正常工作八小時，我怎麼想都難以理解要怎麼十倍，因為一天只寫了一小時不到的程式。
開發速度
十倍的速度通常會聯想到「開發速度」也就是寫程式的速度需要有其他人的十倍快速，那麼打字速度要非常快速、對程式熟悉到像是背起來一樣，能夠馬上將程式碼寫出來，而不需要查文件或者思考。
如果有實際寫過程式就會發現，真實的軟體開發中需要花費大量的時間思考、理解問題，然後再多次嘗試錯誤的狀況下找出最適當的做法。
除此之外，軟體之所以是軟體就是為了能夠被「經常修改」而設計，因此隨著市場的變化公司也會要做出對應，原本耗費力氣思考、理解的商業模式都會被推翻，那麼又得重新同樣的過程不斷重來。
如果單純以程式碼的產生速度來計算生產力，以我的經驗作為基準，能做到其他人的三倍速度幾乎是極限，大約是一天寫一到兩小時左右的程式。除了寫程式本身的時間，思考、開會理解需求等等事情加起來，能以三倍速寫程式差不多就是一到兩小時。
我個人的 WakaTime（用於記錄編輯器活躍時間）過去一年的紀錄，包含下班時間平均是兩個多小時的活躍時間。
準確度
當一個需求進來，你需要開發一個功能的時候你會怎麼做？是否能夠找到一個一次就做對，或者做完之後就滿足交付（Delivery）的條件。
當我們無法再從「撰寫程式」壓榨出更多的生產力時，就需要尋找其他方法。這個方法就是找到一個最有效率的開發方式，至少要先從減少錯誤開始。常見的做法就是撰寫測試，透過測試來提供大量反覆修改驗證的保護。
然而，寫測試本身並不代表我們正在實現正確的功能。因此還需要去了解商業需求，正確的理解需求之後，才能夠設計正確的測試案例，透過每一次實作和修改都能更加接近商業需求，進一步縮短交付的時間。
即使能夠以接近幾乎沒有誤差的狀態交付，我們仍需要對需求本身反覆檢驗，在大多數時候規格提出的功能跟實際需求仍會有差異，我們還需要敏銳的察覺真正有價值的部分，以交付最有價值的部分為目標。
到此為止，我們才能從每一次的需求中找到關鍵的需求（可能是規格的 20% 左右）以此為基礎跟將程式撰寫能力磨練到頂尖的三倍速度相乘之後，預估能十五倍左右的生產力，扣掉一些雜項和誤差，達到十倍工程師並非完全不可能。
以工程師的角色要跟產品負責人（Product Owner）協調並不容易，要能夠點出使用者真正需要的部分，並且討論出關鍵的部分加以實作，就表示自身也需要具備對產品不亞於負責人的理解。
到這個階段，我們會發現撰寫程式的能力只是手段的一種，軟體工程師的本質仍是將商業目的實現的角色，能夠做到多準確的實現，取決於對於所在產業和產品的理解。
我們很少會去思考，要實現多少的功能就可以達成原本的目的，在開發初期能夠先確認原有目標可行，再去評估是否需要額外改善體驗的機制可以減少很多來回修改的狀況。
回顧 2024
今年的回顧用「最值得一提的事物」來跟大家分享這一年，這也包括原本就有持續進行閱讀 5 ~ 7 本書、一年兩次的連載也都還在繼續進行中。
不同的是明年開始要從 Technical Lead（技術領導）轉換為擔任 Architect（架構師）的角色，今年在主管的協助下提升了職級後，過去的累積讓自己很快地又接近下一個等級，因此會有許多不同的挑戰需要完成來迎接下一次的進階。
在這個過程中，我思考了過去一年多自己能在團隊貢獻約 80% 生產力（從開發工作分配來估計）的原因，很大一部分是將以往對於「資深工程師」的許多想像拋棄，以實際處理商業問題的角度思考。
這並不是能在短時間內所能達成的狀態，在過去幾年的時間投入在敏捷開發、軟體測試、學習商業知識、時間管理等等不同的面向，最終累積足夠的能力才得以獲得這樣的成果。而下一個階段，則是需要解決個人能力的拓展性（Scalability）從對個人生效，到能夠適用於團隊、公司。
這一年 AI 雖然有驚人的進步，然而只是將許多高階職位的前置準備縮短，仍然有許多單純靠「技術」難以解決的問題，這些正好是我明年開始要迎接的新挑戰所需要去面對的。