Traversy Media 的 Brad 分享了開發者在 side project 上常見的困境：為什麼我們總是開始新專案卻無法完成它們。影片逐一分析了六個核心原因——點子太多、啟動成本過低、過度工程、追求完美、缺乏截止日、以及職業倦怠——並提供了實用的解決策略。核心訊息是：完成專案是一種技能，重點在於專注、動能和知道何時該宣告完成。

原影片連結：https://www.youtube.com/watch?v=Y_JQti8YLn0

影片重點

• 開發者天生有創造力，但點子太多反而導致什麼都做不完
• 軟體專案的低啟動成本是雙面刃，讓人太容易開始卻也太容易放棄
• 過度工程（overengineering）是殺死最多 side project 的頭號原因
• 「完成比完美更重要」——Progress over Perfection
• 沒有截止日的專案注定無法完成，自律是關鍵技能
• 職業倦怠時不要再給自己加壓，把 side project 當成健身習慣
• 明確定義「完成」的意義：能讓人開始使用的 MVP 就是完成
• 完成專案是一種可以培養的技能，與天賦和智商無關

詳細內容

[00:00] 開場：你也有做不完的 Side Project 嗎？

Brad 一開始就拋出一個讓所有開發者心有戚戚焉的問題：你有多少次因為一個新點子而興奮不已，開始設計 UI、建了首頁、做了登入頁面，然後就再也沒碰過那個專案了？他指出這是非常普遍的現象，你不孤單，連他自己也是如此。

這不代表你懶惰、不上進或是個差勁的開發者。接下來他將逐一分析為什麼這種情況如此常見，以及你可以怎麼做來改善。

[00:33] 原因一：點子太多，執行力不足

開發者天生就是有創造力的人，我們喜歡建造東西和解決問題。每次打開 Reddit、Product Hunt，甚至只是開車經過某個地方，都會冒出新的想法。尤其在 AI 時代，這個現象增加了十倍——Brad 坦言自己的點子多到根本追蹤不了。

問題在於我們不斷追逐新點子，而不是為當前專案建立動能。Brad 建議：把所有點子寫下來，但一次只做一個。為 MVP（最小可行產品）設定截止日，先建立動能，其他的點子隨時可以回來做——它們不會跑掉。

[01:21] 軟體專案的獨特性：啟動成本幾乎為零

Brad 提出了一個有趣的觀點：軟體開發和其他任何專案最大的不同，就是幾乎不需要什麼成本就能開始。他拿木工蓋棚子做比較——你需要花錢買工具和材料、找到場地、做實際的體力勞動，如果放棄了會損失很多。

但軟體開發只需要打開文字編輯器就能開始，除了自己的時間以外不需要投入任何東西。雖然進入生產環境需要支付基礎設施費用，但前四分之三的開發過程幾乎不花錢。這個低門檻反而造成了我們容易開始卻不容易完成的問題。

[02:17] 原因二：過度工程是 Side Project 殺手

Brad 認為過度工程殺死的 side project 比其他任何原因都多。例如你決定做一個部落格——一個相對簡單直接的東西——結果你開始建微服務架構、設定 Docker 容器、打造自訂認證系統，連首頁都還沒出來。

如果你的目標是學習這些技術，那當然沒問題。但如果你想快速完成一個部落格，就不要過度工程。他的建議是 KISS（Keep It Stupid Simple）：一個 repo、一個資料庫、一個框架，先把東西做出來。你隨時可以重構和擴展——等真的有人在用的時候再說。

[03:23] 原因三：害怕不完美

我們會告訴自己：專案還沒完成、UI 還不夠精緻、程式碼可以更乾淨、配色方案不完美。然後就不斷調整、不斷修改，直到完全失去興趣。

Brad 的建議很直接：「Done is better than perfect」（完成比完美更重要）。忽略腦中那個一直告訴你「還沒準備好」的聲音。你不需要像素級完美的設計或完美的邏輯才能發布 side project，你需要的是動能。他妻子教了他一句話：「Progress over Perfection」（進展重於完美），這句話在這裡非常適用。

當然，這不是說要隨便拼湊、寫爛程式碼或讓 AI 全部生成然後不管品質，但在「隨便做」和「追求完美」之間存在一個合理的中間地帶。

[04:17] 原因四：沒有真正的截止日

做客戶案子或在公司上班時，總有壓力要完成。但個人專案很容易就放在那裡不管，因為沒有人會追究你。你需要學會對自己負責——Brad 認為這是一項技能。

他分享了自己的經驗：他已經很久沒有老闆或主管了。很多人說想自己當老闆，但你真的得「當自己的老闆」，也就是要有紀律、對自己負責。他建議建立外部問責機制：在 Twitter/X 上發文宣布「我這週五要上線」，告訴你的追蹤者、朋友、甚至告訴你的狗——讓時程變成一個真實存在的事。

[05:31] 原因五：職業倦怠

很多開發者把 side project 當成 hackathon 來做——週六連續做 14 小時，然後三週不碰。這是通往災難和精疲力竭的配方。

Brad 建議反過來，把 side project 當成健身習慣：每天 30 分鐘就好。這點時間會慢慢累積，而且能持續建立動能。如果你的正職已經讓你感到倦怠，那現在可能不是開始 side project 的好時機。等工作壓力緩解後再開始，不要在已經滿載的盤子上再加東西。

[06:18] 原因六：從未定義「完成」的意義

另一個專案殺手是你從來沒有定義什麼叫做「完成」。你不斷寫程式、調整、加 dark mode、第三次重寫認證系統——當然永遠完不成。

Brad 指出，現實中大多數軟體專案永遠不會真正「完成」到你再也不需要碰它的程度。他所謂的「完成」是指：做到能讓人開始使用的程度。把它上線，在社群媒體上展示出來——這也是流程的一部分。

他的方法是永遠以 MVP 為目標。MVP 不代表專案最終就長那樣，它可能會完全改變，但至少你有一個可以部署、可以讓人使用的東西。

[07:14] 結語：完成專案是一種技能

Brad 最後總結：完成專案是一種技能。這跟天賦無關，跟智商無關，而是關於專注力、動能，以及知道何時該宣告完成。

如果你的專案資料夾裡有十個做到一半的 app，就選一個。建立動能，不要想太多。設定截止日，然後 Ship It。

我的想法

這部影片雖然只有七分半鐘，卻精準點出了幾乎每個開發者都經歷過的痛點。Brad 的建議看似常識，但「知道」和「做到」之間的距離往往是最難跨越的。

特別值得注意的是他提到「AI 時代讓點子數量增加了十倍」這個觀察。在 AI 工具大幅降低實現門檻的今天，開始一個專案變得更容易了，但這同時也意味著「完成」的挑戰更大了——因為你隨時可以跳到下一個更有趣的點子。

他把 side project 比喻為健身習慣（每天 30 分鐘）而非 hackathon（週六 14 小時）的建議特別實用。這其實和軟體開發中持續交付（Continuous Delivery）的理念不謀而合：小步快跑、持續前進，比一次性的大爆發更能產生實際成果。

另外，「建立外部問責機制」的建議也呼應了 Build in Public 社群的核心理念——公開你的進度，讓社群的期待成為你前進的動力。這對於獨立開發者來說是一個非常值得採用的策略。