Neutrino's Blog

¶ 0. 緣起

2025 年 1 月 3 號，我的新書《程式設計原來不只有寫 CODE！銜接學校與職場的五堂軟體開發實習課》總算正式在書局上架，我萬萬沒有想到前前後後總共竟然歷時一年才將這本書順利完成，出書所花的心力和勞力遠超出想像，但市場也用它的熱情回應我，讀者熱烈迴響，有幸登上了天瓏書局銷售排行的第一名（2025年一月），如今我可以驕傲的說，我也是一位「暢銷作家」！

（《程式設計原來不只有寫 CODE！》在天瓏書局畫面 （2025/04 截圖），202501 銷售排行第一名）

一切的開端要回到我碩士時期，那時候參加了 IT 鐵人賽，以「資工基本素養」為題報名了影片組，之所以會有這題目，是當時我就察覺到即便是資工系學生，仍然常常缺乏程式開發的基本素養。例如知道怎樣使用除錯器、版本控制、維護專案等等，這也不能怪學生，畢竟這本不是學校該教的內容，但業界卻期待學生一入行就應該懂這些知識，於是產生了學校與業界之間的鴻溝，所以不管是我早期拍的影片，或是現在出的新書，出發點都是要彌補學校沒教但卻很重要的「資工基本素養」。

關於資工基本素養可以看此書的〈序〉，我有將內容公布在此網站上。

碩士拍完影片之後，我一直就掛念著哪天我應該把我想教授的內容編寫成書，但碩士時期不僅程度不足，也忙於研究和交換，後來去日本工作，又花了一些時間適應新公司和職位，總算在工作滿一年半時，感覺時機成熟了。

¶ 1. 聯絡出版社

2023 年 12 月，某 A 出版社聯絡了我，說看到我 IT 鐵人賽的文章，想找我寫書，對方看中的是我很久以前寫的瀏覽器原理系列，當時該系列甚至還是當年軟體組冠軍，可惜那時博碩還沒跟鐵人賽合作，所以雖然拿了冠軍，瀏覽器原理系列也沒能出書。如今已經過了好幾年，我對瀏覽器原理早已失去興趣，同時我也不認為該主題能有多少客群，所以我將我想寫「資工基本素養」的想法告訴 A 社，和對方簡單視訊了一下，對方認為沒問題。

不過跟 A 社溝通的過程，對方感覺沒有很專業，甚至給我一點隨便的感覺，我想對方只是在亂槍打鳥，遇到剛好想出書的作者大概就「願者上鉤」。不過 A 社的聯絡確實給我信心，讓我真正下定決心要把寫書這件事情完成。

如果我今天是一個素人，我可能就答應 A 社了，但是對我來說，當時我已有大量網路文章寫作經驗，而且在社群網站上也有一些粉絲，並且我早已有新書的構想，且我知道這主題（關於資工基本素養）一定會熱賣，我不認為有任何出版社會拒絕我。

題外話，對於一個素人來說，想出書的最佳路徑是參加 IT 鐵人賽，博碩為官方合作出版社，每年會從參加選手中找出有潛力的主題協助出書，這方面我是挺贊同的，有一個正規管道培養新興作家是好事。

於是，我越想越不對勁，我對書的內容有信心，所以我如果要出書，我就想要找最大、最專業的出版社，A 社實在讓我不放心。剛好朋友 Claire 跑來跟我說她也被 A 社群問了，但她跟我有一樣想法，只想找最好的出版社。此時 Claire 在考慮聯絡博碩，而博碩在我心目中確實是台灣電腦書出版社的龍頭之一，如果能找博碩出書肯定不錯。恰好她有博碩的聯繫管道，告訴我可以去聯絡博碩編輯 Abby，於是我終於和博碩牽上線了。

題外話，我希望有機會能讓歐萊禮出此書的英文版。

¶ 2. 提案與簽約

聯絡上博碩出版社後，對方有簡單調查了一下我的背景，我的條件應該是沒啥問題，所以我和編輯直接有個簡單的電話討論，談話內容針對我想怎樣出書，以及出版社會如何協助我完成。在談的當下其實我對出書整體流程還是很陌生的，當時我最在意的部分是書名、封面、內文我有沒有絕對主導權，但事後來看我其實多慮了，我根本就是 120％在主導整本書的走向，也許是因為我比較龜毛，且自詡美感不錯，編輯和美編基本上都是尊重我的意見。

簡單的電話完後，基本上出版社答應幫我出書，不過我仍需要先提交作者規劃書給他們審查，然後確認沒問題後就會簽約。

¶ 2.1 作者規劃書

作者規劃書包含了「書名」、「書籍特色」、「市場同質書差異分析」、「頁數預估」、「全書交稿日期」以及「大綱」等資訊，我大約花了一週完成。

¶ 書名

書名其實取個大概就好，因為最後真正要註冊書籍時會再攪盡腦汁想，那是全書交稿後的事情了。

¶ 書籍特色＆市場分析

書籍特色和分析市場對我來說也不是問題，因為我這本書的特色就是「市場上沒有競爭對手」，這是我還是學生時就發現的事情，「資工基本素養」如此基本重要的題目，市場上竟然真的沒有！（至少華語圈沒有）這也是為什麼我懷抱著強烈的使命感，必須成為寫出此書的第一人。

¶ 預計頁數

頁數估計當時我估 400 頁，雖然編輯當時說可能會有點厚，但根據我平時買書的印象，中文技術書 400 頁應該是正好的厚度。寫稿的時候是用 A4 大小去寫，通常抓乘以 1.2～1.3 左右是成書的頁數，所以如果我預計要寫 400 頁的話，草稿應該要 300～330 頁左右，雖然我後來已經刪了一大堆內容，但最後交稿時是 350 頁 A4，編排完是 488 頁，一不小心就讓書變太厚了。

¶ 預計時程

我提交計畫書時約是 2024 年 1 月左右，當時預計花六個月左右寫完，編輯還跟我說平常大家都三個月左右寫完，最後我實際上花了約九個月寫完的。我想每個作者都會有自己寫書的步調吧，前面提到的 Claire 寫書時只花了一個月完成三百頁的書，我覺得那個速度真的超神。關於寫書的細節留著晚點再說。

¶ 制訂大綱

大綱實際上是整份作者規劃書花最多時間的環節，而且是最重要的部分，雖然我大概有概念我想要寫哪些內容，但要怎樣把各個部分串連起來可就難了。知識為什麼需要透過「書籍」的形式來傳授，與其它媒介的最大差別就在於章節安排與編排設計，這是從網路上零散的知識得不到的完整度體驗。我在構思大綱時就決定要說一個漂亮的故事，書本內容前後必須呼應，讀者看完會有恍然大悟的感覺，例如寫程式最重要的是開發環境，有了環境之後要有好的編輯器，編輯器裡面有各式各樣的功能，其中搜尋功能在後面講述怎樣閱讀程式碼和進行除錯分析時會很實用，而版本控制的功能在後面說明怎樣進行團隊合作程式開發時也會用到，瞭解如何進行團隊合作後才會知道為什麼專案品質很重要，以及 CI/CD（持續整合/持續部署）為何重要。你會發現所有知識環環相扣，最後像拼拼圖一樣拼成一個完整的「資工基本素養圖」。

¶ 2.2 簽約

作者規劃書繳交後出版社會評估出版的可行性，如果對方有意願出書的話，就會提供一份制式化合約，合約內容包含書名、作者名、時程、分潤、預計售價、預計頁數等。其中書名、作者名正式登記 ISBN 前都是可以再調整的，時程和預計頁數也是可以邊寫邊調整，但通常只能是微調，時程牽扯到出版社安排人力，所以預計什麼時候截稿就要盡力在那時候完成，而頁數大概可以有正負一百頁的誤差。

與作者利益最相關的部分是分潤，以素人來說我感覺是比較沒有談判空間，我的合約是以累進制來談分潤，每多一千本銷量就增加幾％這樣，但以目前書本普遍銷量不佳的情況下，我當時合約內談的銷量數字感覺過於樂觀了。

最後一點是合約沒寫，但我出書後才覺得非常重要的一點，要確認電子書相關事項是否有在合約內，例如電子書要什麼時候上架，格式是什麼，要在哪些平台上架等。博碩出書的政策是電子書會晚兩個月上架，但合約內並沒有特別寫，如果我是先知道的話，我會要求實體書與電子書同時上架。基本上我認為實體書與電子書是不同的市場，延後上架電子書反而讓我辛苦做的行銷成效打折扣。

作者與出版社雙方都確認合約沒問題就可以簽約了，簽完之後就是漫長寫作的開始。

¶ 3. 漫長寫作期

¶ 3.1 樣章

不管你已經有書稿了，或是打算從頭開始寫，出版社都會要求你繳交一個樣章，該樣章用來評估寫作風格與格式是否符合出版社預期，出版社會根據樣章給建議和回饋。一些比較常見的錯誤會在這時候被挑出，例如提到「圖ＸＸＸ」時，該圖必須出現在第一次文字提及之後、專有名詞需要以粗體標示，此外根據內容也會進行溝通，例如對話框出現的時機、版面元素的設計（本文、補充、練習題）等。

樣章是用來確保作者與出版社對書的內容的質量有一樣的期待，過程大約會花剛開始寫作的數週，來回討論一兩次後，就會定下風格，之後書本的其它章節基本上就是照著相同的風格去寫，此外藉由樣章去瞭解常見的錯誤，也可以避免日後全書完成時才要回來進行大量的修正。

¶ 3.2 學習用 Word

對於會寫程式的人來說，我們大概會比較習慣用 Latex 或 Markdown 來寫文件，不過出版社要求書稿要是 Word 文件。所以我整本書的書稿都是用 Word 來寫，一開始用起來真的頗不順的，因為過了大學之後就沒再用過 Word 了，而且平時用 Word 也頂多是寫單一頁面的文件，所以這還是我第一次用 Word 寫數百頁的文件。

為了讓我接下來一年過的比較輕鬆，我得先學習怎樣高效地使用 Word 寫作，一開始確實比較痛苦一點，花了很多時間瞭解基本功能使用，像是如何建立大綱（Outlining），如何設計與建立不同的風格：無行號程式碼區塊、有行號程式碼區塊、inline 程式碼、鍵盤按鈕樣式文字等等，如何加入圖片說明文字並自動編號，蠻多功能都是寫的過程中邊寫邊學。一旦將 Word 文件設定好後，接下來其實就蠻有效率的，像是我設定設定不少快捷鍵，「Ctrl+Shift+1」是將文字變成本文，「Ctrl+Shift+2」是將文字變成程式碼格式，「Ctrl+`」將文字變成 inline 程式碼等等，習慣了之後其實用 Word 其實也沒有比較慢。

我寫完書後才想到，出版社雖然要求 Word 檔，但之後還是會用 InDesign 來做編輯，所以我其實可以用 Latex 寫完轉成 Word 給出版社就好。由於我這本書不太需要用數學式，所以用 Word 寫也沒特別感受到痛苦，但如果要寫一本數學式很多的書的話，我可能會認真研究一下從 Latex 轉 Word 的可能性，但不論如何學會用 Word 也是一件好事。

¶ 3.3 內文圖片

圖片我覺得是一本書最麻煩的部分，這邊眉眉角角很多。首先，圖片需要編號，但這編號可能會隨著寫書的過程動態調整，雖然在 Word 中可以設定自動編號，但如果要大調整時，還是常常會格式亂跑，這方面還是 Latex 好。此外圖片需要另外儲存高畫質版本，之後美編排版會用到，另外儲存的圖片則需要手動一個一個編號，所以基本上要等到交稿前再根據 Word 內容上編號就好。

圖片的設計也是很大的學問，我們希望圖片越多越大越好，這樣每個步驟都很詳細又清楚，但同時實體書籍的頁數是有限制的，此外還要顧及自己加工圖片的時間成本，所以必須取得一個平衡。事實上我會希望盡可能減少圖片，但有些章節真的非放不可。給大家一個觀念，在《程式設計原來不只有寫 CODE！》裡面的圖片，平均處理時間都是一小時起跳，這是因為我必須要整要截圖的內容的位置與大小，去刪改圖片內不必要的資訊，然後再加上導引用的數字編號，最後還要確認該圖片縮小到實體書的大小時，該圖片要呈現的重點都還是清楚可見的，實際上這一系列的流程非常花時間。

題外話，出版社並不會提醒你圖片該注意的所有細節，所以很多部分要自己有 sense 一點，像是黑白印刷的話圖片顏色的對比要調整好、圖片最大可以放到多大（書籍會留邊）、可不可以將圖片轉 90 度、圖片文字最小可以到多小等等，這些最好都能事先溝通清楚，在寫書時就處理好，免得最後校稿時才要處理。

我剛開始寫的時候，圖片還在用 PhotoShop 處理，效率很差。後來我的設計師老婆跟我說可以用 Figma，我一用就如獲珍寶，真的是太好用了，後來整本書都是用 Figma 來編輯圖片，少數情況才需要用 PhotoShop 額外修改。Figma 本來就是用來做 UI/UX 設計用的軟體，所以拿來做簡易的圖片編輯簡直輕輕鬆鬆，它有很好的分層、控制元素、元件設計等，因為太好用了，我認為每個工程師都該要會使用，所以在這本書的最後面，〈工程師必備的繪圖工具〉章節中我特地加入 Figma 的介紹，這是我寫書前始料未及的。

Figma 示意圖，其中畫面裡為本書的部分圖片：

另外有些內容其實用「影片教學」會更適合，這種部分用圖片呈現就會非常麻煩，試想你要解釋一個流程：按下 A 按鈕進入 B 頁面，接著滑鼠移到 C 按鈕上，會有個浮動視窗跳出來，接著點裡面的 D 按鈕，進入到 E 頁面，這個流程如果用影片來講解的話就行雲流水，但在書本上只能用大量的圖片加上文字來解釋，此時就會瞬間出現大量圖片要穿插在該章節中，編輯圖片就會很痛苦也很花時間。

事實上，我還盡可能減少使用的圖片了，一張圖片可以解釋多個概念，可以跳過的畫面就不放圖片，即便如此本書中介紹 VSCode 用法和如何用 GitHub 的部分，還是分別使用了二三十張圖片，可想而知我在寫這些章節時內心的崩潰。

最後就是一定要確保圖片的授權沒問題，所以每張圖片我都是親自創作或編輯，就算網路上有類似的圖片，我也是自己重畫，如下面這張「縮排波動拳」的圖，大家可能在網路上有看過類似的圖，但一來是版權不明，再來是解析度也挺差的，所以後來我就自己畫了，這種原創的圖片所花時間則更可觀，可能一個下午就沒了。最後，如果真的要用網路圖片，一定是使用版權聲明完全沒問題的。

節錄《程式設計原來不只有寫 CODE！》書中「圖 5-11 縮排波動拳」：

¶ 3.4 規律寫作

《程式設計原來不只有寫 CODE！》最後寫完是約二十萬字，聽起來很多，對嗎？從一月動筆到十一月交稿，經歷了十個月，約 300 天，代表每天差不多要寫 666 字，這樣看起來似乎又還好了，差不多就是 2/3 頁 A4 的字數，每天多少寫一點日積月累，終究是能辦到的，而人們往往對於積沙成塔的成果而感到吃驚。

每天一張 A4 究竟是難或不難呢？靈感來時文思泉湧，一晚可以寫個兩三頁，但有時候卻連短短的一兩百字都像卡在喉嚨的魚刺一般，痛苦地、緩慢地，才能擺脫。章節是早就安排好的，所以只需要按表操課每日填一點，最終還是把這二十萬字填滿了。

寫書跟做任何事情一樣，貴在持之以恆。

¶ 3.5 範例程式碼

作為程式設計類書籍，程式碼肯定少不了。程式碼對於軟體工程師來說很簡單，但放在書裡面的程式碼就沒那麼簡單了。軟體工程有一個概念是「KISS」，也就是「Keep it simple and stupid.」的意思。書裡面的程式碼一樣要遵守 KISS 原則，越直觀越簡單越好，任何稍微複雜的地方最好都加上註解，可以的話其它段落最好詳細解釋。

我們都知道書的空間有限，所以程式碼必須越精簡越好，解釋的文字也是越少越好，但與此同時仍不能讓程式碼變得難以理解，或是刪除必要的文字解說。完整的程式碼肯定是無法全部放入書裡，雖然有些書會這樣做，但那樣完全不切實際，因此在這本書中，我將最關鍵的程式碼片段擷取出來，並且確保只閱讀擷取片段是能理解該章節要呈現的內容，剩下的程式碼則放在 GitHub repo 中，讀者可以去下載完整程式碼，並實際跑跑看。

最後我最得意的部分，這本書程式碼的排版應該是市面上電腦科技類書籍中數一數二講究的，光是程式碼樣式就附行號與否和附檔案名與否的差別，此外程式碼的字體還區分英文、註解英文、註解中文，並且加上必要的高亮或粗體來強化表示，每個程式碼區塊的程式碼也都是精心調整過的，不會出現斷行位置奇怪、沒有對齊或是過長程式碼的問題，我敢說一定贏市面上 99％的書籍。

¶ 3.6 插畫

這本書的封面跟章節開頭插畫我是找我的好朋友簡嘉彤幫我畫的，好的插圖絕對是替一本書畫龍點睛。我不太建議使用 AI（是少 2025 年初當下的 AI）來產生插畫，除非你只是想要一些很炫麗的圖片，不然考慮到插圖與書本內容的相關性、每張圖片的連慣性、插圖的風格表現等，還是跟插畫家討論如何創作比較能控制產出，雖然花錢但是更有效率。

以技術書來說，一本書用到的插畫數量可能不會太多，像我的書總共是封面、人物設定x2、章節插畫x5，但即便如此，如果每張插圖要力求完美的話，大約一張圖也需要花個好幾天到一週，所以最好在截稿前一兩個月就先找好插畫家，才能確定交稿時能連同插圖一起繳交。

一張圖如何產生的呢？以我的例子來說，一張插圖首先要進行畫面的發想，根據該章節內容思考畫面應該長怎麼樣子，我和畫家會分別畫出非常簡陋的草稿，一起討論要採用哪一種版本，並且要如何調整畫面內容，像是人物的姿勢、線條的角度、畫面的配置等，畫面確定之後，畫家會繪製精細的線條版，接著來回討論修整小細節，確定線條都正確之後才進行上色，上色完一樣要進行修改，全部步驟都完成才終於完成一張圖。

我請朋友畫圖的報酬是大約一百本書的版稅，以現在普遍賣不了多少本書的情況來說，插畫無疑是一個巨大的成本，但我相信插畫有其必要性，精美的封面圖片和生動的章節插畫，會讓人更想去拿起書並往下翻，並替內容提供更鮮明的印象。另外封面主圖自己找插畫家設計通常也比較好，如果讓出版社自行設計的話，通常就會是比較單調的圖庫素材，然後你就會發現市面上的電腦書封面都很單調，永遠都是圖庫素材加上一堆放大的文字，了無新意。

要注意的是，如果想要讓插畫在書中嵌入得更完美，最好先跟出版社詢問詳細的書本參數，像是內文一頁的大小、封面主圖可以放置的位置、顏色是否有限制之類的，我自己的經驗是，當時沒有先問好一頁的大小，所以請插畫家畫章節插畫時長寬比沒有到很完美，導致圖片有稍微縮放產生一些白邊，雖然瑕不掩玉，但依舊感覺有點可惜。

（插畫範例：第一章章節頁面）

¶ 4. 交稿後

歷經十個月痛苦的「趕稿」日子後，終於可以交稿啦！實際寫書時間因人而異，有些人一兩個月就能寫完，此外也跟書籍的厚度有關。交稿當下有終於解脫的感覺，但實際上卻還閒不下來，從交稿到送印中間大概會經歷一個多月，這期間需要想書名、設計封面、校稿好幾次，有些書甚至還會打樣，通常會抓一到兩個月內上市。

¶ 4.1 書名

取書名是一種藝術，書名的好壞甚至決定一本書 50％的成功率，如何讓人一聽到就覺得「好像很有趣」可是困擾我許久，最一開始我取的名字是「資工系的基本素養」，但這名字聽起來實在不是很吸引人，後來簽合約時出版社給了「程式設計實習生特訓 N 門課」的書名建議，但我依然覺得有點俗，於是交稿後就重新思考書名應該要什麼好。

在與朋友討論以及與 ChatGPT 討論後，得到了「程式設計原來不只有寫 CODE」的點子，當下就覺得這個名字應該夠響亮，不但念得很順，而且能進一步引起讀者好奇，不只有寫 CODE？那還有什麼？此外這書名又有種輕小說書名的感覺，給人一種比較新潮且有故事性的感覺，正好呼應本書以實習生「小悅」在職場實習的背景故事。

至於書名的副標部分，「銜接學校與職場的五堂軟體開發實習課」則算是對市場的一種妥協，主流市場還是習慣以 N 堂課、N 個技巧、N 個心法這種命名方式，甚至連費曼的書都叫做《費曼的 6 堂 Easy 物理課》，但副標還是能更有效的讓讀者瞭解書籍主要的內容，「銜接學校與職場」強調了學校學不到的知識，而「軟體開發實習課」很明顯是針對軟體開發做介紹，而這全部的背後其實都指向我原本的書名，也是全書的宗旨，也就是資工學生的基本素養。

我蠻滿意這本書的書名，硬要吹毛求疵的話，我更希望可以就叫做《程式設計原來不只有寫 CODE！》就好，而英文翻譯則是更加精簡，叫做《Beyond Just Coding》。

考量到我未來可能會想要出不同語言的版本，因此我在取書名時也一同想好英文名字，在註冊 ISBN 時其實可以一同把英文名也註冊，不過一般出中文書不會這麼做，所以要特別要求出版社，最後我的書「正式」全名叫做《程式設計原來不只有寫 CODE！銜接學校與職場的五堂軟體開發實習課 = Beyond Just Coding: Five Essential Lessons from Classroom to Career in Software Development》，甚至更長了！

¶ 4.2 書封和書底

封面直接影響大眾對這本書的第一印象，所以我不希望封面長得太普通，因此前面有提到我是請朋友幫忙畫封面插圖。以當今流行的封面來說，主要都是大大的書名加上一大堆關鍵字，然後放上一些素材插圖，沒有說好不好，只能說不符合我的美學。基本上封面出版社也都是尊重作者的意見，所以最後我的書的封面使用的插畫、排版、字體、顏色都是我做最終決定的。

封面設計除了主圖和標題配置之外，還會需要想一下要不要加一些宣傳語、推薦語、重點摘要等，不少書封面寫得密密麻麻，我最後決定乾淨就好。而書底通常也會包含一大堆資訊，包含簡介、重點摘要、推薦語，這部分我就沒有特別的設計要求，主要要考量的比較是資訊有沒有給足，而所有文案都必須由作者親自去想出來，這點倒是跟我想像的不一樣，我本來以為編輯會負責把書封書底的文案想好，但全部由作者來操刀也不是壞事，對我來說 100% 的掌握度我反而更開心。

¶ 4.3 排版和校稿

交稿之後，編輯首先會對內文做初步的校稿，比方說錯別字、大陸用語、標點符號等，作者會再次檢查過，這時就可以送交美編來進行排版。在排版之前會先進行試排，挑出一個章節來進行編排，然後根據作者意願來調整，比方說下圖摘自試讀頁（p192）：

試排時就要告訴美編每個書籍元素要怎麼呈現，字體、字元大小、大標小標格式、圖片位置、程式碼樣式等等，在試排時就要把大部分的格式都定案，接下來整本書就會按照該格式去編排。由於這本書是技術書，所以我對程式碼的編排特別用心，樣式包含有無程式碼行號、有無程式碼檔名、程式碼是否有高亮，此外中文英文字體不一樣，註解也有特別改灰色加斜體，並且所有程式碼都有根據書本最大寬度做斷行的調整，我敢說市面上沒有一本技術書的程式碼編排像這本《程式設計原來不只有寫 CODE！》一樣用心。

原本以為寫完書之後就輕鬆了，但其實校稿一樣很花時間，整本書反覆讀過不下二三十遍。一般校稿大約會安排三次，第一次會大修，再來就是幾次的小修，由於我比較細心和嚴格，一直抓到編排上錯誤的地方，最後來回進行了五次才收工，校稿完作者確認都沒問題了，就會拿去送印。

¶ 4.4 送印

到了送印階段就沒作者的事了，編輯會給作者看一下試印的成果，但不太會發生意外，接下來就會排程印刷，在預計上市日的前幾天送到出版社，再由出版社分送給經銷商和書局。

¶ 5. 出版

正式上市前約兩週就會先在網路書局上架預購，屬於作者的戰爭這時候才真正開始，如果書一本都賣不出去就是寫辛酸的，前面的努力雖然沒有白費，但你的書就只會躺在圖書館的書架上，我們都不希望這樣，所以接下來需要瘋狂地去做行銷。

¶ 5.1 行銷

我們都知道行銷非常重要，但很遺憾出版社並不會幫你做行銷，這也是我入行才瞭解的遊戲規則，現今的出版市場的遊戲規則就是以量取勝，出版社每個月都會出版數十本新書，而眾所皆知當今出版業利潤並不高，所以基本上出版社不會有預算幫你的書做行銷，除非像是張忠謀寫自傳這種大咖例外，一般的作者還是得靠自己想辦法推廣自己的新書，從開始預購到上市後的一個月期間，就是行銷的重要時間。

推廣書的方法包含社群發文、下廣告、找 KOL 幫忙宣傳等，但我們一本書其實賺不了多少錢，這年頭能賣個一千本就謝天謝地了，所以除非你是張忠謀或愛莉莎莎，不然盡量選擇不花錢的宣傳方式（當然不在乎是否賠錢的話例外）。

根據我實驗，Threads 的帳號的第一篇貼文的加成非常高，要好好把握，幾乎保證可以有 10k 左右的曝光，此外臉書粉專、LinkedIn、X 等社群平台也都是盡量發文，如果能找到比較大咖的工程師、教授、老師幫忙宣傳也會很有幫助。我自己是一直保持每幾日貼文持續了大約一個月，有時候會意外的受到演算法眷顧就可以有比較多的流量，我估計我在認真宣傳的其間大概引入了約四五十萬的曝光，但轉換率其實非常低，實際上購買書人數大約只有 0.2％左右而已，這年頭電腦書真的非常難賣了。

¶ 5.2 排行榜

出書的那陣子我每天在看書局的銷售排行榜，這個過程很像在玩遊戲——玩著名為出書排行榜的遊戲，儘管這個遊戲幾乎毫無技巧可言，僅有規則就是想辦法讓自己排行不斷往上，而看著自己不斷一名一名往前爬真的很有成就感，那陣子一大樂趣就是每天關注自己的書在各大平台的銷量排名，同時也是倍感壓力，我真的非常希望自己花了一年的心血可以得到豐碩的回報。

玩遊戲過程中你不會知道自己做了哪些事情有幫助，哪些則是完全徒勞無功，例如我到處在社群網站上發文，拜託其他工程師幫忙分享，送了五本書給台大同學當做「獎學書」等等，就我自己感受而言，絕大多數的行動都不太有成效，但我相信好書還是能慢慢形成口碑和造成影響力，像是得知大學教授買了 25 本送同學，聽到有科技公司主管推薦我的書給下屬，這些成果無疑都是對我這本書的肯定。

終於，某天我的排名達到第二名，而前方則是當時的勁敵《為你自己學 Python》，其作者是高見龍，另外著有長青暢銷書《為你自己學 Git》，跟他較勁十分困難，客觀來說人家知名度比我高，宣傳管道也比我多（程式教學機構），更糟的是我根本不知道如何去贏得這場遊戲，所有作為都是盲人摸象。但高見龍作為領先者卻是十分有風度，他主動表示願意幫我進行宣傳，在 podcast 和 IG 上都有提及我的書，甚是感激。

雖然我不知道怎樣玩這場遊戲，但亂玩一通之下，終於還是讓我等到這了一天，一天早上起來檢查排名的時候，發現我終於我坐上了第一名寶座，之前的壓力如下了一場傾盆大雨後一掃而空，鳥兒站在樹梢上唱歌為我祝賀，我自然也忍不住到處向親朋好友來炫耀一番。爬到頂點，也宣告著這場遊戲的「勝利」，後來我其實就不太在意書的銷量，我已經為了這本書辛苦太久了，而我也得到我想要的報酬，而且我相信一本好書是會持續發酵醞釀，我有自信這本書會是中文界軟體工程師的「聖經」。

¶ 5.3 版稅

在一開始跟出版社簽合約的時候其實就會談好版稅，一般行情是 10～20％，並且還可以有一些附加條件，應該都是非常自由的，例如我自己的版本是每多賣一定數量的書，版稅會往上成長 1％。書籍上市之後，每次再刷時會拿到前一刷的版稅，直到合約中止時，取得未結清的實體書與電子書所賣出的剩餘版稅。出版社版稅入賬時已經先扣 10％稅了，如果稅率跟自己收入不符合的話，應該是報稅時還有再做特別申報來調整。

¶ 5.4 銷量

一開始寫書的時候還抱著幻想，希望自己的書可以大賣個幾萬本，但事實證明，以技術書來說，能賣個幾千本就偷笑了，並且其實要登上天瓏書局榜首所需要的銷量大概就是一千本左右而已。即使技術書不好賣，我想這本書在長尾效應下最終大概有機會賣個一萬本。

比起更通俗的「Excel x AI」纇書籍，或是投資管理之類的書，動輒就幾萬本輕鬆賣，技術書真的是太難賣了，儘管我的書已經是屬於技術類受眾較多的類型，買的人依然寥寥無幾，有時還是會有點灰心，不過這年頭大部份的技術書都賣不出去，你在天瓏書局網站上看到的所有技術書，基本上除了前三名，剩下的書大概只會一刷，銷量不超過六百本。如今大 AI 時代可以預期書只會越來越難賣，通常大家寫書都是期待一些附加價值，像是演講邀約、個人成就等等，而我則是因為發現市面上缺少一本「資工基本素養」的書，秉持著捨我其誰的胸懷大志而寫下此書。

因為每本書普遍賣不了幾本，所以不少作者或出版社便選擇用書海模式來投放市場，造成台灣技術書品質參差不齊，充斥著大量的「免洗書」。

¶ 6. 結語

我認識不少軟體工程師，其中不少人都有一個作家夢，但付諸實行的人太少太少，多數技術強者不願意花時間，同時寫書的付出與報酬也確實不成正比，多數人現今也不怎麼看書了，但吊詭的事情是，沒有人留下文字，那 AI 的知識則從那而來，人類的文明能不斷流傳與演變，最重要的媒介就是文字，不管是是紀錄在實體或數位上的文字，都能永久地傳承下去。

我喜歡分享知識，也希望推廣「資工基本素養」，這本書有幸獲得不錯銷量，並且獲得不少讀者好評，甚感喜悅。

在這篇文章中我完整分享寫一本技術書的心路歷程，其中寫書的方法其實是用各種領域，更廣泛地說，應該與各種知識傳播的媒介多少有雷同之處。在此我希望號召更多有志之士，將自己的知識以各種方式紀錄並傳播，可以是部落格、書籍、影片、程式碼專案、podcast 等等，越多人投入知識傳播，越多人能夠受惠，人類的文明就是如此進步的。

最後，如果如果你還沒取得一本《程式設計原來不只有寫 CODE！》，請試著買一本或借一本，這絕對是不會讓你失望的好書！