英文原文：Taylor Fausak 編譯：伯樂線上 – 黃利民
編寫程式碼大致如寫散文。先從大綱開始。可以是一些要點或虛擬碼，或許已經胸有成竹，亦或是記錄在筆記本上，這都不重要。
寫完了初稿。這是能執行的最短、最簡單的東西。它可能不是很漂亮，但已把要點表達清楚。你可能注意到了它的不足之處，更為重要的是，知道為什麼會有（不足之處）。你只想讓它能跑起來。它可以稍後再精煉。
而這正是下一步要做的：終稿成品。成品將打磨、審查、編輯、除錯。處理特殊問題（“edge case”），提供來源，匹配戶型，並正確格式化。這型別的東西，就是一篇出色散文或一段程式碼之類的樣例。
故而散文和程式碼相似。它們的開發方式亦相似。為什麼“軟體開發人員”對你重要？因為你能用作家所使用的策略來提升改善你的程式碼。
（伯樂線上配圖）
雖然同行評審實際上是書面作品的評審標準形式，但我感覺有點不適用於程式碼。所有程式設計師往往只專注於他們的程式輸出。除了展示專案，有一個不錯方法可以抵消這個，自公佈程式碼。（A good way to counteract this is is to publish the code itself in addition to showcasing the project.）Github 的出現，使這個屢見不鮮了。
但成為一個更出色的程式設計師，甚至比這還容易。要做事情就是閱讀更多的程式碼。優秀的作家大量閱讀，優秀的程式設計師亦當如此。你閱讀的程式碼不一定非常實用，可以只是非常有趣。可能稍後就能派上用場。
幸運的是，這兩個建議相輔相成。通過公佈你的程式碼，你給了其他開發人員提供閱讀材料。他們的程式碼將會提高改善，期望他們也將公佈程式碼。如此一來，你也能從中學習。
譯註：本文比較短，大致就算是一篇隨筆。有關閱讀程式碼的文章，推薦閱讀 Alan Skorkin 的這篇更為詳細的文章：《閱讀優秀程式碼是提高開發人員修為的一種捷徑》
英文原文：Taylor Fausak 編譯：伯樂線上 – 黃利民
【如需轉載，請標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】