胡百敬，具MCT、MCAD、MCSD國際認證執照。並獲選爲微軟“最有價值專家”MVP（Most Valuable Professional）。現任臺灣恆逸資訊資深講師、微軟專業顧問、聯合報系技術顧問。擁有多年系統分析、設計與實際經驗。曾參與許多大型項目開發，主講微軟臺灣全省百場以上大型研討會，同時也是一位活躍於IT媒體的專欄作家。
半年多前，胡百敬老師在Blog中寫了一篇文章《撰寫信息書籍注意事項》，其中給出了若干條言簡意賅的指導意見。看到目前園子裏很多朋友正在準備撰寫/翻譯技術書籍，Dflying希望能夠和大家分享一下這幾條意見，並總結自己的實際寫作經驗加上一些心得體會。（以下粗體部分爲胡百敬老師的原文）
名聲第一，利益第二，不要在別人案頭留下罵名。
之所以在第一條就提到了這一點，是因爲這是個態度問題。不可否認，對於某些朋友來講，寫書是創造財富的一條行之有效的道路，特別是那些胡拼濫造之作，一個月就可以寫出一本——網上搜索一下代碼、文章，甚至連調試都沒有調就這樣寫了出來；或者是長篇累牘的代碼，從<html>到</html>一字不少；更有甚者直接引用大段的官方文檔……
自己的名聲，要一點一滴的珍惜。書籍一旦出版，就像刻在了石頭上，可能流芳百世，也可能遺臭萬年。動筆之前，先端正我們的心態。
書籍定位清楚，沒有適合所有人的書。
很多朋友，包括我在內，在第一次寫作的時候都喜歡長篇大論，非要事無鉅細將所有東西都涵蓋纔好。然而貪多嚼不爛，不要妄圖寫出百科全書——即使要寫百科全書，也不會是你的第一本書。現在軟件開發都講究敏捷，小迭代，寫書的時候難道不也應該參考一下麼？太多太長，主題往往淹沒在滾滾文字中，難免最後樣樣通、樣樣鬆。
章節目錄由簡而深，必要內容放在前面章節，選擇性內容放在後方章節。
這一點是人之常情，符合人類（即使是動物也如此）的理解習慣，沒什麼好說的。最完美的就是，某一張開始承接上一章，結尾引出下一章。
第一章最後寫。
第一章往往起到統領全書的作用：若是介紹一個框架，那麼這一章就將大概把框架的特性，結合本書所講的內容列出來。若是介紹語言，那麼則會逐一闡述語言的特性、歷史、發展等。若是開始的時候就寫第一章，那麼難免隨着寫書的過程不停地修改、調整，造成不必要的時間浪費。
我在撰寫《ASP.NET AJAX程序設計》一書時，就是沒有經驗先寫的第一章。剛剛察看了版本控制系統，這一章已經有了獎金200個版本，幾乎每天都要修改……比較一下最初版本和最終版本，早已面目全非……
不要有漫畫書的狀況出現。在圖與圖間最好加一些引述，說明。否則書會像漫畫書，讀者不容易連續想象圖文之間的關係。
每一張圖示都要在正文中有所提及。每一張圖示的說明都要表達明確的意思，不要寫“圖3 代碼3-4的運行結果”，而要寫“圖3 將XXX屬性設置爲YYY之後，頁面將顯示ZZZ”。還有，珍惜讀者的￥或$，只添加必要的圖示和代碼——這兩者非常佔版面。
具體不要抽象，分析比較不要批評。
在比較的時候，不要簡單地列出一個表格：A高、B低、C一般……要具體地分析出是什麼造成了這樣的結果。
參與比較的各個項目，往往在某些領域、某些時期都有獨到的優勢，很難說出誰就一定比誰好。所謂蘿蔔白菜，各有所愛，特別是針對不同平臺、框架的比較，更要格外小心，力求保持中立、客觀。若是一本講.NET的書中不停地帶有詆譭Java的詞句，那麼相信誰都不會願意看。
不要中英混雜，每小節第一次引用的術語，英文連同中譯一起出現，以後僅出現中譯。
很多朋友在實際工作，或是在寫Blog的時候經常喜歡中英文混雜，當然我不是批評這樣的用法。但畢竟圖書——白紙黑字印出來的——需要體現嚴肅性。“寫code的時候不test，checkin了之後build break你才後悔”——這樣的話萬萬不能出現在書稿中！
但對於某些專業詞彙，特別是在翻譯時遇到的中文譯名不是那麼流行或是有爭議的詞彙，則在括號中保留原詞不失爲一個好辦法。如果可能，在書中還要給出統一的關鍵詞翻譯參考，要是能夠順帶解釋一下爲什麼選擇這種譯法，那就更是錦上添花了。
引用在線說明時，要小心 Review 其內容，一般翻譯錯誤很多，最好能參閱原文在線說明。
這一點比較明確，就不再多說了。不過要提及的是，引用任何非原創的作品都要得到明確的版權許可，以免日後帶來不必要的麻煩。
翻譯時，注意中英文習慣不同，少用定冠詞(如“一個”)，人稱代名詞(你、我、他)，被動式。儘量「意譯」，而不要「直譯」。
特別要提到的儘量避免被動語態，中文很少很少使用。
說到意譯，更要把握好不同文化之間的差異，有些外國人都看得懂的俗語、或是他們文化中的幽默，中國讀者卻根本摸不到頭腦，這是一定要加上足夠的譯者注，或是乾脆用中國的等同故事替代。
補充一條：英文中的長句子，特別是定語重句一定要拆開，不要讓人看到譯文之後都能聯想到原文。
每日要有習慣性產出，脫稿是從第一天開始，不要妄想趕進度。
堅持——這是寫作中最重要的一條。寫書不是寫Blog，心情好我就一天一篇，甚至一天幾篇，心情不好我就一個月都不管。寫書講究的是涓涓細流，積少成多。人都是很懶的，都會爲自己找到很多借口，有了第一次脫稿，那麼就會有第二次，第三次……好比一個函數有幾個間斷點沒什麼問題，但要是間斷點太多，就不可積了。若不是對你的毅力非常有把握，那麼最好把你預先計劃的撰寫時間乘以二！
寫完一章後，隔些日子重讀內容，務求文字精簡，圖像精緻。
慢工出細活，一點都不假。不要寫完一章馬上開始校對，等過了半個月再重新來看，你會很快發現自己當初的幼稚……
文筆是苦練出來的，沒有渾然天成。說話與寫作是兩回事。
多看書，多看技術書，看看人家是怎麼寫出來的。把代碼寫好並不等於能把書寫清楚，把牛皮吹破也不見得下筆就有神。
找個有經驗與耐心的人審稿。
書寫完了，還要留一點時間給別人看看。一個人的能力總歸有限，錯誤、誤解都是在所難免，要不寫代碼的時候怎麼要Code Review呢？