寫作吧，菜鳥工程師！（下）

好，假設我們已經找到想寫的題目了。可能是昨天解掉的那個 Bug，可能是剛學會的某個工具，也可能是對某個技術趨勢的看法。

然後呢？然後打開編輯器，看著那片空白的頁面發呆，十分鐘過去了，還是一片空白，然後開始懷疑人生：「我真的適合寫文章嗎？」

這種感覺，寫過文章的人應該都經歷過。其實問題不是「適不適合」，而是我們對「開始寫」這件事有過多不必要的期待。

空白頁沒有想像中可怕

也許各位在動筆之前，腦中已經有一個完美的文章樣貌。例如要有漂亮的文章配圖，文章一開頭就要吸引人，中間要有邏輯，結構起承轉合，最後結尾要有深度，最好還能讓讀者看完有種醍醐灌頂的感覺。

帶著這種期待去寫的話，對著空白頁面發呆大概就不會太意外了。因為我們不是在「寫文章」，而是在「想像一篇完美的文章」，這兩件事差很多。

先跟大家說我自己經歷過的寫作真相：

好文章不是寫出來的，是改出來的。

所有我們看到的好文章，背後都有一個很醜的初稿。那個初稿可能邏輯混亂、用詞重複、有些段落根本不知道在講什麼。但沒關係，那就是初稿該有的樣子。所以我給大家的第一個建議就是允許自己寫出爛東西，接受不完美。

這不是降低標準，而是認清寫作的本質。初稿的目的不是完美，而是「存在」。我們沒辦法修改一篇不存在的文章，但可以修改一篇很爛的文章。

有本我蠻喜歡的書《Bird by Bird》，作者用了一個「糟糕的初稿（Shitty First Drafts）」的說法，所有的好作家一定都曾經寫過糟糕的初稿，差別只在於他們不會讓別人看到那個版本。

所以，先把東西寫出來，先不用管它多簡單，先有再說。

讓起步變簡單的小技巧

除了心態上的調整，還有一些實際的方法可以讓動筆變得容易一些。

寫給某個特定的人

不要想著「我要寫給所有對這個主題有興趣的人」，這太過抽象了。試著想像一個具體的人，可能是剛進公司的新人、半年前的自己、你以前教過的學生，或是某個在 Discord 上問問題的同事。寫給一個人，比寫給「大家」容易太多了。當有一個具體的讀者在腦中，很多問題就會自動有答案。要從哪裡開始講？看他已經知道什麼。要講多深？看他的程度。要用什麼例子？就用這位假設讀者能理解的情境。

用說話的方式寫

如果真的不知道怎麼下筆，可以想像那個人就坐在你面前，然後把想解釋的東西「講」給他聽。怎麼講，就怎麼寫。很多人寫文章會不自覺地切換成「正經模式」，開始用一些平常不會用的詞彙、寫一些繞來繞去的句子。但讀者不需要這種正式感，他們需要的是能理解的解釋。口語化不代表不專業，很多時候反而更專業，因為真正理解一件事的人，才有辦法用簡單的話把它講清楚。

從中間開始寫

沒有規定一定要從開頭寫起。這有點像拼圖，我們不會從最左上角開始一個一個拼，通常是會從容易下手的地方開始，例如先把邊框拼起來，再把中間的部分慢慢填滿。如果想不到怎麼接續前面的段落，就先跳過，接著寫後面的內容。如果想不到怎麼開頭，就先跳過，從最有把握的部分開始。可能是某個技術細節、某段 code、或是某個很想分享的觀點。我自己寫文章的時候，開頭通常是最後才寫的。因為把中間和結尾都寫完之後，這時候已經知道整篇文章要說什麼了，開頭反而會變得容易。

我在寫書的時候也是，最一開始的序言都是最後才寫的。因為那時候已經把整本書寫完了，知道這本書的重點是什麼，才能寫出一個好的序言。

一個可以參考的流程

寫了一陣子之後，大概會發展出自己的寫作流程。如果剛開始不知道怎麼進行，我有一個可以參考的版本。

先花點時間看看別人怎麼寫這個主題。我不是要你抄襲，而是要了解這個領域的「對話」目前大概進行到哪裡了。這個主題別人已經寫過什麼？有什麼是還沒被寫過的？你能補充什麼不同的觀點？這個階段也可以幫你避免重複造輪子。如果發現這個主題已經有人寫得非常好了，可以考慮換個角度，或是找另一個題目。

接著把想講的東西列出來，不用很詳細，條列式就好。這個階段的目的是讓自己對整篇文章有個大概的輪廓，知道要講哪些點、大概的順序是什麼。有些人喜歡用心智圖，有些人喜歡用條列式，用什麼工具都可以，我自己很多時候就只是用最簡單的記事本而已。重點是把腦中的想法具象化，讓它們變成可以看到、可以重新排列的東西。

然後就是寫初稿了。這個階段的重點只有一個，就是寫完它。不要邊寫邊改，不要回頭看前面寫的東西對不對，不要因為想不到一個完美的詞就卡在那裡。這些事情都是之後的事，現在的任務就是把草稿生出來。可以設定一個時間，比如一小時，在這段時間內就是一直寫，不管寫得好不好。很多人會發現，當強迫自己不要回頭改的時候，寫作速度會快很多。

初稿完成之後也不一定要馬上進行修改，放置個幾天也沒問題。這不是拖延，這是因為剛寫完的時候你對內容太熟悉了，不容易馬上轉換成讀者的角度來看文章。不趕時間的話，隔一小段時間再回來看，可能會比較容易發現哪裡不通順、哪裡解釋不清楚或是哪裡可以刪掉。進行修改的同時可以不斷的問自己，這段話是必要的嗎？這個詞可以換成更簡單的嗎？這個解釋夠清楚嗎？如果我是第一次看到這篇文章，我能理解嗎？

更多題目類型

除了上一篇提到的三個問題，我們還可以從不同的「文章類型」來找靈感。

踩坑文與 Bug Hunt 大概是最好寫、也最受歡迎的類型了。寫一個自己遇到的問題，從發現問題、嘗試各種方法、到最後怎麼解決。這種文章就像偵探故事一樣，讀者會跟著我們的思路走，一起經歷那個抽絲剝繭的過程。這類文章的好處是，不需要是專家才能寫。事實上，專家反而不容易寫出這種文章，因為他們太熟練了，不太會踩到這些坑。新手踩的坑，往往是其他新手也會踩的。

事後檢討也是很好的題材。如果工作中有什麼事故發生過，系統為什麼掛了？怎麼發現的？怎麼修好的？之後做了什麼來避免再犯？大部分的讀者喜歡看別人的災難，不是幸災樂禍，而是可以從別人的故事學習。不過寫這類文章要注意，把重點放在經驗分享和學到的教訓，不要甩鍋或指責誰誰誰。

週末的 Side Project 也可以拿來寫，不管多小、多無聊、多沒用都可以寫，這類文章通常對工程師比較有吸引力。沒有人會嫌專案太小或太簡單，重點是做了些什麼、學到了什麼。

設計決策與取捨是我認為最有價值的文章類型，但也是最少人寫的。當我們要選擇用 A 技術還是 B 技術的時候，是怎麼決定的？為什麼選 PostgreSQL 不選 MySQL？為什麼選 GraphQL 不選 REST？這種「為什麼」的文章特別珍貴，因為網路上大部分文章都只告訴我們「怎麼做」，很少解釋「為什麼這樣做」。但在實際工作中，最難的往往不是怎麼做，而是決定要做什麼。

還有一種比較特別的題材：抱怨文。對某技術的挫敗感，像是「我放棄 Webpack 了，它的設定檔讓我崩潰」、「為什麼 CSS 這麼難學」。這類文章容易引起共鳴，因為每個人都有對某個技術感到挫敗的經驗。當然，抱怨歸抱怨，如果能在抱怨之餘分析一下為什麼這個技術讓人挫敗、有沒有什麼替代方案或應對策略，文章會更有價值。

讓題目源源不絕

知道可以寫什麼類型的文章之後，下一個問題是怎麼讓自己隨時有題目可以寫？

追蹤技術社群。X、Reddit、Hacker News 或是加入一些技術 Discord 群組，這些地方經常有人在討論各種話題。看看別人在聊什麼，有時候會激發寫作靈感。也許看到有人問了一個問題，我們剛好知道答案，那就可以寫一篇文章詳細解釋。

注意團隊討論中反覆出現的問題。如果在公司的 Discord 或 Teams 裡看到同樣的問題被問了三次以上，那就是一個很好的寫作題目。「這個專案要怎麼設定本地開發環境？」被問了十次。好，寫一篇詳細的設定指南，以後有人問就丟連結給他。這不只是幫助別人，也是幫助自己，因為不用再重複回答同樣的問題了。

隨時記錄靈感，這非常重要，這讓我們在需要的時候有題目可以挑。當突然想到「欸這個可以寫」的時候，立刻記下來。用什麼工具都行，什麼都好，因為大部分的人類不擅長記這種突如其來的靈感，不記下來可能一轉頭就忘了。

我試過好多種方式，有使用手機筆記軟體，甚至也想過用小紙條寫下來放口袋，或是用錄音筆錄下來，但錄音筆要用的時候常常找不到，找到的時候可能就忘了要錄什麼。最後發現最有效的方式是手機內建的語音備忘錄，我發現 Apple Watch 跟語音備忘錄是很棒的組合，因為想到的時候通常手上沒辦法打字，而用這個方式只要手舉起來講話就可以了，我找了好多方法最後發現這個方式最適合我。

不同類型題目的寫法

聊完了題目類型，接下來講講每種類型適合怎麼寫。

解 Bug 的文章很適合用偵探小說的方式來寫。一開始先描述現象，例如「使用者回報說頁面偶爾會整個白白的像當機一樣」。接著帶著讀者一步步找問題，先檢查某些設定、排除了什麼可能、又發現了什麼新線索。過程中可以保持一點懸念，不要太早揭露答案。這種寫法的好處是，讀者會跟著你的思路走，學到的不只是「這個 Bug 怎麼解」，而是「遇到這類問題可以怎麼思考」。

「我們怎麼做出這個東西」這類文章，重點在於展示工程決策的過程。不只是說「我們用了 A 技術」，而是要解釋「為什麼選 A 而不是 B 或 C」。遇到了什麼限制？做了什麼取捨？如果重來一次會有什麼不同的選擇？這種文章的價值在於決策背後的思考過程。技術會過時，但思考方式不會。

檢討文有點像是公開的事後報告。這種文章需要一點勇氣，因為可能得要承認自己搞砸了什麼。不過寫得好的話這種文章可能會最受歡迎。重點是誠實，不要變成自怨自艾。發生了什麼、為什麼會發生、學到了什麼、怎麼避免再次發生，把這些講清楚就好。

而觀點文則需要有明確的立場。「我認為微服務在大多數情況下是過度工程」或「TypeScript 的型別系統被高估了」這種帶點爭議性的觀點，會比「微服務有優點也有缺點」這種中立陳述更有價值。有立場不代表可以沒有依據，你需要解釋為什麼這樣想、根據是什麼、在什麼條件下這個觀點成立。觀點可以主觀，但論證要客觀。

應該寫在哪裡？

文章寫好了，要發在哪裡？

自己架部落格是很多工程師的第一選擇。用 Hugo、Hexo、Astro 這類靜態網站產生器，搭配 GitHub Pages 或 Vercel，不用花錢就可以有一個自己的部落格。好處是內容完全屬於自己，不用擔心平台倒閉或改規則。缺點是沒有現成的讀者，一開始可能寫了半天沒人看。但長期來看我會最推薦這種做法，因為這就是在建立自己的資產或個人品牌。

各位現在正在看的這篇文章，平台就是我自己用 Ruby on Rails 開發的部落格系統。我自己也有用 Hugo 架過部落格，但覺得有些功能要客制化比較麻煩，再加上我想維持寫程式的手感，所以後來就自己寫了一個。這件事其實沒有想像中困難，現在甚至直接請 AI 幫你 Vibe 一下，可能幾個小時就可以完成一個簡單的版本了。

相對的，如果想要有現成觀眾，可以考慮現成的平台。Medium 和 DEV.to 是國際上比較多人用的。Medium 的讀者比較雜，什麼主題都有；DEV.to 則是專門給開發者的，技術文章在那邊比較容易被看到。

有些人會好奇，就直接寫在社群平台就不用選系統了，而且馬上就有人可以看到。先不論社群平台的字數限制，我相信大家也都知道社群平台的內容很容易被洗掉，今天發的文，三天後就沉到不知道哪裡去了，說不定文章的主題不被平台喜歡還可能會被演算法濾掉。即時性的評論或短想法，發在社群上沒問題，但如果是花了時間寫的長文，還是建議發在可以被搜尋到、可以長期存在的地方。

不要花太多時間糾結這個問題。選一個順眼的平台，先發了再說，寫了十篇之後自然會知道哪個平台適合自己，然後再來想下一步。

按下發布沒有這麼可怕

決定好要發在哪裡之後，下一個問題可能會卡在不敢按下發布鍵。很多人會卡在這一關，因為總覺得還不夠好、還需要再改一下，或是發出去之後會不會被別人電。

這種心情我可以理解，不過網路文章不是印刷品，發布之後還是可以改的。如果發布之後發現有地方寫錯了，或是有人指出我們的理解有誤，誠心的說聲謝謝然後修正就好。這不是什麼丟臉的事，這是很棒的學習的過程。

至於發布之後要不要推廣？要不要貼到自己的社群版面？看你自己，但不用太刻意。在社群分享一下是合理的，畢竟寫了就是希望有人看到。不過要控制頻率和方式，避免讓人覺得是在洗版或打廣告。

有個我自己常做的做法，就是有人問到相關問題的時候，就在底下的留言貼臉開大...不是，是分享自己寫過的文章。這種分享是有脈絡的，比較不會那麼快就被覺得是在打廣告（但其實也是廣告沒錯）。當然，前提是文章內容真的有幫助，不然就會變成自我感覺良好或是炫耀。

從一篇文章開始

文章寫多了之後，可能會有一些有趣的發展...

有些文章可能會變成演講的素材。把一個主題寫清楚了，要變成二十分鐘的分享其實不難。我很多場技術研討會的題目都是從我自己寫過的文章發展出來的。

有些系列文章可能會變成更大的計畫。寫了五篇關於某個主題的文章之後，可能會發現「欸，這些整理一下好像可以變成一本書？」有不少技術書的作者，早期也是透過自己的部落格文章開始累積稿件的。

甚至，這些文章可能會帶來意想不到的機會。有人可能因為看了你的文章來找你聊聊，有人可能邀請你去研討會分享，有人可能想跟你合作專案。不是說寫了文章就一定有這些機會，但只要持續寫、持續累積，是真的有可能發生。

以上的情況我都遇過，不過這些都是後話，現在最重要的是動手開始寫第一篇。

不用想太遠，不用規劃什麼內容策略，就是找一個想寫的題目，然後把它寫出來。寫得不好沒關係，發布了沒人看也沒關係，先跨出第一步就對了。

要不要開始試試看？

希望這兩篇文章讓你有一點點「好像可以試試看」的念頭，也許不久的將來，會有人在某個 Discord 頻道問了一個問題，然後有人丟出了你寫的文章連結。那個人會說：「哦哦原來是這樣，謝謝！」然後你會收到通知，發現自己幾年前寫的東西幫到了一個陌生人。

那種感覺還不錯的，好啦，可以去寫了 :)