網路產業充斥著副業專案成長為成功事業的傳奇故事，而我，就像許多人一樣，在完成正職工作後，常常會投入一兩個想法的實驗。

雖然這是一個誘人的前景，但投入副業專案並非總是陽光燦爛、名利雙收——有時候它們就是無法成功。如果你正在閱讀這篇文章，你可能最近已經放棄（或正在考慮放棄）一個副業專案。我們許多人都經歷過。說真的，被忽略的副業專案在這個階段已經變成了一種開發者迷因。

話雖如此，我經常收到初學開發者尋求建議的電子郵件，而我最近注意到一個日益增長的主題是，他們擔心自己無法像期望的那樣快速或大量地完成副業專案。

這種焦慮完全可以理解。當主流的開發者「奮鬥文化」的智慧是「永遠都要上線」時，而科技面試官會例行性地以應徵者課外程式碼輸出來衡量他們時，那些被遺棄的副業專案可能就不再那麼有趣了。

這讓我覺得不太對勁。我們聽了這麼多副業專案的成功故事，但如果我們能更公開地談談那些失敗的呢？我們許多人在工作中都會進行回顧，但個人專案卻沒有得到相同的待遇。為什麼我們不照亮我們在那些沒有結果的專案上花費的時間呢？那些「當時聽起來是個好主意」的被遺棄品；那些仍然困擾著我們開發環境的 `node_modules` 資料夾的墳場。

我想談談我很久以前做的一個副業專案；一個我在部署的同一天就放棄的專案。

我的伴侶是拉脫維亞人，幾年前，我開始學習她的語言。由於拉脫維亞是一個小國家，詳細的拉脫維亞語學習資源有點稀少，但儘管如此，我還是取得了不錯的進展。直到我發現拉脫維亞語有文法格（grammatical cases）。

如果你以前從未接觸過「格」，這裡有一個簡單的介紹：

像英語這樣的語言使用詞序和介詞，例如「for」、「to」或「in」，來為句子中的每個單字添加意義。如果順序錯了，或者你漏掉了介詞，句子可能就無法理解了。例如，「Tom gives the book to Anna」聽起來很自然，而「Tom the book to Anna gives」則不然。

格改變了這一點。它們不依賴詞序和輔助詞，而是改變每個單字的結尾，以顯示它在句子中的作用。回到拉脫維亞語的相同例句，「Tom s dod grāmat u Anna i」（強調標示功能性結尾）。字面翻譯回英語，這句話大概是「Tom-主格 給 書-受格 Anna-對向」。

從語言學的角度來看，格是一個很酷的系統，因為你不再需要關心詞序。但是，作為學習者，這是一個問題，因為你需要關心你學到的每個單字的各種結尾。拉脫維亞語總共有七個格，兩種文法性別（每種有三種不同的變化模式），名詞可以是單數和複數。總結來說，大約有 84 種可能的結尾需要記憶。

所以，對於以英語為母語的人來說，格可能是一個很大的挑戰。幸運的是，我同時也是一個開發者，因此我天生就認為我可以用程式碼解決一切。如果我能建立一個測驗應用程式來幫助我學習名詞結尾呢？這聽起來像是一個副業專案 🚀

我想讓我的應用程式保持簡單。雖然我還有很多文法要學，但我只專注於名詞變化，這有助於我將最初的概念縮減到一個最小可行產品（MVP）。

測驗機制會呈現一系列拉脫維亞語名詞，使用者需要將名詞變化成適當的結尾。為了保持趣味性，測驗允許使用者犯三次錯誤後結束，我還會加入一個簡單的高分系統來追蹤我在過去測驗中的表現。

技術堆疊也會很簡單。在規劃時，Svelte 3.0 是當時最閃亮的新技術，所以我決定用它來製作使用者介面。我知道我想將所有東西託管在 Netlify 上，所以對於後端，我會編寫幾個無伺服器函數來呈現問題和檢查答案。主要的單字列表可以從一個靜態 JSON 文件提供，而且由於我將是唯一的用戶，我可以安全地將先前的測驗結果和高分儲存在本地儲存中。我暫時不需要資料庫。

至於我將如何實際檢查答案，這需要一些研究。在廣泛閱讀了變化模式以及各種名詞的分類方式後，我決定最簡單的選擇是建立一個高度依賴正規表達式（Regex）的系統，來剝離名詞詞幹並附加適當的後綴。

有了不錯的計畫後，我開始編寫程式碼。

經過一整週的晚上投入專案，我完成了 MVP 的最後潤飾。我將所有東西部署到 Netlify 並開始初步測試。

使用者介面簡單但尚可接受，並且在行動裝置上運行良好。測驗問題順暢地進行，並且在三次錯誤後結束，正如設計的那樣。在測驗之間，儀表板正確地顯示了每個單字的命中和未命中統計數據，並且高分在不同會話之間得以保留。我對一切都按計畫進行感到滿意，便開了一瓶啤酒，開始訓練單字結尾。

很快就發現我的應用程式有一個我沒有預料到的巨大問題。測驗太容易了。更糟的是，如果我沒有犯錯三次，測驗就會無限期地繼續下去。使用起來一點也不好玩。

我絞盡腦汁想出各種方法讓測驗更有趣，但最終，我明白了：這個問題實際上無法透過程式碼解決。結果是，在設計和編寫所有必要的邏輯來測試各種名詞結尾的過程中，我已經被動地學會了形成它們所需的規則。

在過去的一週裡，我花了很長的晚上時間研究和建立一個應用程式——目標用戶只有一個人——而我實際上已經不再需要它了。糟糕。

在我所有被遺棄的副業專案中，這是讓我思考方式改變的一個。

即使我最終的「產出」永遠不會被真正使用，但完成這個專案本身間接達成了我的目標。這讓我產生了一個重要的體悟：我們經常將被遺棄的副業專案視為「失敗」，但它們的成功其實是視乎觀點的。

儘管一些科技招聘人員可能讓你相信，副業專案的成功不一定需要由一個精美的、已上線的產品來定義。我們從事的是一個實用的媒介，任何的開發經驗，無論好壞或被遺棄，都是有效的經驗。

如果你能夠擺脫上線壓力，而是將它們視為一次性的原型設計，副業專案就成為了實驗的絕佳草稿紙。正如我在開發我的拉脫維亞語應用程式時發現的那樣，即使是編寫程式碼這個行為本身，也可以成為解決問題的有效工具。

這並不是說我們應該忽視這些專案被遺棄的原因——反思仍然很重要——但我發現從長遠來看，專注於已取得的進展會感覺更有建設性。

在我放棄拉脫維亞語專案後，我重新審視了放在我筆記型電腦上其他停滯不前的副業專案。以前我會為一連串的失敗和浪費的時間而抱怨，現在我可以重新專注於那些進展順利的部分。

在一個專案中，我可以看到我最初是如何學會用 Go 語言製作 API 的。在另一個專案中，我對自己如何處理 PostgreSQL 中的 GIS 地圖數據感到印象深刻。在另一個廢棄的目錄中，我看到的只是一個損壞的動畫——我後來重新審視並將其演變成這個網站。

我仍然定期從事副業專案，但我的觀點和動機已經不同了。

我給正在為副業專案奮鬥的初學開發者的建議是，永遠要確保你是為自己而做，並且是出於正確的原因。與其將你的第一個專案純粹視為賺大錢或給招聘人員留下深刻印象的手段，不如首先將它視為學習和探索可能性的手段。

一旦你累積了足夠的經驗（也就是說，放棄了幾個專案），剩下的通常就會隨之而來。副業專案應該是富有創意和樂趣的。如果你發現完成專案開始給你帶來壓力，或者更糟的是，讓你感到筋疲力盡，那麼請毫不猶豫地放棄它。很有可能，如果你仔細觀察，它已經為你帶來了巨大的價值。

我是一名自由創意開發者，幫助優秀的人們打造雄心勃勃又易於使用的網路專案。