2008
Two Ways to Solve a Problem
這些年下來，我反覆觀察到一個現象：程式員各有一套慣用的方法來克服自己遭遇到的問題，這些解題習慣可區分成兩種，工程師多只專精其一，只有少數能任意在兩者間自在地切換。
2007
The Art of Design
為甚麼好的設計會來自於差的設計呢？ Scott 在 Why Good Design Comes from Bad Design 提到攻讀 CMU Computer Science 博士時選了門介面設計課，第一堂課上他發現一位年輕人素描著隨身聽的各種變異版本，而且圖紙上已經堆積了三、四十種不同考量的版本了。 Scott 於是湊過去問這個小伙子「幹嘛費勁畫那麼多草稿？」
2005
程式的再利用（Reuse）
就一個程式設計師而言，增進程式碼與設計的“再利用”程度是一個值得關切的議題。所以，這次就來探討一下程式的再利用。
程式設計的箴言──擷取自《資料結構與程式設計》
前一陣子轉貼了《教堂與市集》的格言後，大家的反應還蠻正面的，於是就趁年假，再為大家剪貼一下《資料結構與程式設計》中的箴言：
程式設計的箴言──擷取自《Writing Solid Code》
這一陣子以來，公司瀰漫在一片除錯的淵藪當中，搞得很多人都顯得心力交瘁，包括我自己也被攪得焦頭濫額。這不禁讓人想起一句品管上的名言：品質是內建的，不是外加的（Quality is build-in, not add-on.）──這時讀來，倍感切心。
軟體開發的時程與風險
上次談了“嵌入式軟體”，這次就談談也出現在《數位式競爭》的“軟體專案失敗常見的原因──時程估計錯誤”：
軟體系統的秩序起源－－《建築的永恆之道》評介之續篇
這一回，就如之前規劃的，來聊聊“軟體構築”。更精確地說，是軟體系統中，秩序的來源。
Literate Programmin
Literate Programming 基本想法是許多程式被人們閱讀的次數遠遠超過被人們執行它的次數、程式員花在看懂程式的時間也往往比撰寫程式碼的時間多得多，所以想辦法讓程式容易讓人看懂就成為一個重要的議題。
[分享] 程式員的個人特質
上次有預告說要寫一篇探討程式設計師人格特質方面的論述，就趁現在補上吧！
Improving The Design of Existing Code
標題都這樣下了，當然要祭出《Refactoring》這部經典囉！
1
(10 marks)
