他的問題已經從「怎麼做」變成了「怎麼做最好/最安全」

Zilk1988年14歲時就開始程式設計，此後嘗試過幾種職業，最終還是在1997年決定成為職業程式師（又稱碼農），現在已經39歲，對此選擇依然無怨無悔。

但是後來他發現一個問題，自己的經驗越豐富，完成專案或任務的時間反而越長。 因為他見過了太多可能會出問題的情況而對選擇躊躇。 比方說，假設他剛想到要寫一段寫入檔的代碼時，電光火石之間他就已經開始擔心起下面的一系列的問題：許可權、鎖定、併發、原子操作、迂回/框架，不同的檔案系統、目錄中的檔數、可預測的暫存檔案名、 PRNG（偽亂數產生器）的隨機性品質夠不夠、操作過程中斷電怎麼辦、API怎麼寫才好理解、文檔應該怎麼寫等等。

簡而言之，他的問題已經從「怎麼做」變成了「怎麼做最好/最安全」。

結果就是他他做出來的版本堅如磐石，但是也導致他完成專案的時間比菜鳥還要長。

Zilk說，他自己精通演算法、熱愛數學，享受複雜專案，專注度也沒有問題。 也許經驗是有問題（儘管已經39歲了），導致害怕犯錯，使得專案費時。 所以他在StackExchange上邀請同行説明他解決這個問題。

下面就是精選出來的解決方案：

Telastyn：

你完成專案並不慢。 以前你認為自己的菜鳥專案做完了但實際上並沒有完。 你應該把品質賣給客戶。 「公司可以做得更快成本更低，但專案真的完成了嗎？ 或者說你願意花幾年的時間找bug嗎？ 」此外，你還應該知道並接受那句老話：「完美是好的敵人。 」

sevenseacat：

「好、快、省只能3選2」。 以前你懂得少所以犧牲了「好」，現在你懂得多了卻犧牲了「快」。

mouviciel：

似乎你的經驗的確不足:)。 教訓：遵守需求即可，不要想其他。 這樣才不會實現不需要的功能。

Satish:

應考慮敏捷方法論而不是瀑布流。 先交付然後反覆運算交付。 此舉有助於降低風險和成本。

DXM:

似乎你加入黑暗面：管理的時候到了。

我不是要建議你放棄程式設計變身經理。 但從你的描述來看你的經驗僅限於技術層面。 寫檔這麼簡單的事情你居然能想到10個方面的問題，稚嫩一點的開發者絕對是想不出來的。 這不是什麼壞事，但是......

黑暗面的一切都與現值有關。 它要考慮的是如何用最小的投入實現最大的產出（成本效益分析）。 商業上的一切事情都要歸結到成本、成功幾率、失敗幾率、潛在回報等問題。 做好這方面的數學然後採取相應行動。

哪怕你是開發者也無妨：忽略許可權和命名衝突的情況下建個暫存檔案只需5分鐘的時間。 淨收益：團隊其他成員可以開始依賴此檔的代碼編寫工作。 這是不是一個完美的解決方案？ 當然不是。 99%呢？ 95%？ 90%？ 這些可能性是存在的。

還要問你一個問題：你對技術債務（注：快速解決但會增長後續維護成本的做法）感覺如何？ 有人認為不應該有技術債務。 我不同意。 跟商業一樣，技術債務讓你可以借到「金錢」和「時間」以便晚點交付某樣東西。 2年做出一個完美解決方案，或者用4個月時間快刀斬亂麻作出客戶可以使用並且購買的東西，哪一個更好？ 判斷當然要因情況而定，但是大多數情況下如果你要讓客戶等兩年的話，客戶可能早就跟競爭對手簽約了。

關鍵是像管理商業債務一樣管理好你的技術債務。 借的錢不夠的話就拿不到最佳的投資回報。 但是負債太高的話利息會把你壓垮。

我的建議是用番茄工作法。 專注于小的時間間隔（番茄），然後為未來的工作/研究分配這些時間段，並且在執行的過程中不斷根據事情的優先順序進行調整。

Saul:

程式設計的一個關鍵是管理並控制好複雜性，這是我的最高優先順序之一。 忽略了複雜性管理，要麼缺陷頻發，要麼軟體的ETA（預計到達時間）急劇增加。

軟體複雜性有很多不同的管理層次和辦法，好的做法可以是這樣的：「任何軟體專案的最高優先都是客戶滿意度，這是客戶期望的函數。 」

換言之，軟體複雜性取決於你控制客戶期望的水準如何。

如果你接受這個觀點，那麼下面兩點也很顯然：

客戶期望必須明示 客戶期望永遠都可以改變且通過協商完成。

你舉了一個很好的例子，「直接寫」還是「無數的其他考慮」。 考慮一下，如果有人詳盡寫下了此二者的需求，雙方的功能描述還是一樣的嗎？

同樣是造飛機，F16能飛，航模也能飛，但那能一樣嗎？

本來我打算把所有建議都摘錄出來的，但是考慮到上述的精彩見解足以解決Zilk的困惑，並且為了踐行這些建議，本文就此打住，感興趣者可參見完整討論。

最後我只補充一句：

你還可以看看麥當勞理論。