現在回頭來看，要先有「想作能維護、易懂的程式」的心理，再去學習物件導向或是設計原則會比較好。會很慶幸自己的前兩個學習的程式語言都分別是 QuickBASIC 和 C，都是滿典型的程序型語言，不能說這兩種程式不能很「物件導向」，但是至少在當時程式入門書都是把它當作程序語言教的。
在帶新人的時候，會很明顯的發現以徧程序的語言(PHP)開始學習速度會比較徧物件導向的 FLEX(ActionScript)來快一些，也比較容易掌握的要如何要電腦完成希望達到的工作。不過程序型的程式有個問題，就是容易「背公式」，看到新人只是把公式背出來，卻不知道為什麼要這麼作，環境一但改變就不懂得修正，就可以知道，這個人的程式水準已經被他自己限制住了。
為了寫出更好的程式，為了不在幾個星期之後，要花上大把的時間回頭看從前的程式，慢慢的我進到的核心程式，或是框架的開發。其實也沒有字面上描述的那麼偉大啦～就是將一些總是會用到的功能作成一個一個能夠被 copy 來 copy 去的工具，至少比較低層、關鍵的功能由自己掌握，而其它較未節的就交給新手處理。一來是不用花費大量時間等到新手基本功打好，二來是避免寫出未來讓我難及維護的程式。
雖然早在開始之前就已經開始接觸物件導的向的資訊，也使用過幾種號稱物件導向的程式語言，不過對於怎麼去規劃好的工具，可以讓其它人「不需要懂、只需要會用」，在當時足足困擾我許久，不過深思熟慮是有回報的，第一個核心函數組，足足撐了三年多，經過幾次功能擴充/調整。直到出現更加由效率的演算法，才在最近被全面改寫。
勇於嘗試不同的寫作模式，我認為是這個階段讓我收獲良多的學習方式。不過前提是在已經有一定程度的基本功，知道要把握什麼樣的分寸，不會一股腦的全面改寫，等到來不及的時候才發現不對。因為本身是維護程式的人，也是撰寫程式的人，所以自己造成的問題大都是由自己面對，在不斷和書上理論印證的過程之中，開始體會到設計理論的想法。
我認為，開始不需要死記理論，能夠了解明白理論產生的原因及目的，是第六的階段。也是目前我達到的階段。
在學習程式的過程之中，我滿喜歡這個以用應用為導向的知識，因為理論的發展都是為了要解決某些問題，不見得每個理論或是想法有個「專有的名字」，因為在實務的角度來看，想法了解了，懂得應用來解決實際的問題就完全足夠。理論的名字只是為了便於團隊合作的溝通，而不是去紀念某一個「偉大的人」。
我曾經去參加一個科系研究所的入學考試，其中一場四題的申論題目中，有一個問到「在 20 世紀一位有名的理論家發表了什麼理論」，詳細的題目內容我已經忘了，只記得它完全沒有提到這個理論家的名字(好像他重要得大家都得知道他似的)。當然，最後我只考慮的了不到一秒，就放棄了這代表1/4分數的題目(實際上也不得不放棄)。
當然，這個科系在我心中的評價也一下子掉到谷底。因為一個只知道背誦名人/名理論的名字或歷史的科系，不會有太多精力在思考如何使用理論來解決問題。考題代表著這個科系的取才方式，既然這個科系不重視應用，那很顯然和我的取向不合。落榜了其實也沒有什麼好難過的。
會扯到學校，主要是想回頭說說現在畢業生，許多都停在第一層無法突破。也就是其實對程式並沒有什麼興趣，只是聯考志願選到，就覺得「只能走入這行」，更有些是覺得「科技行業不錯」因此就在大學裡混了四年。很天真的以為，只要能夠從大學畢業，就有能夠作的事情，拿到不錯的薪水。
但是現實是，現在的我看不到大學在教「有用的東西」，這不只是課堂上教的內容部分已經過時，更加嚴重的問題是教給這群學生錯誤的觀念及態度。學生們總是在等範例，修修改改看起來功能出現了，就拿去交差了事，完全不管程式是否還有改進的地方。只要需要有了一些變化，是範例中沒有的，那就完全傻在那裡不知道要如何處理。
如果遇到沒有學過的技術，也沒有想要主動學習的欲望。就好像小學生一樣，抱怨考試題目出到沒教過的範圍，所以作不出來是理所當然。遇上幾次這種人就足夠讓我筯疲力盡，不單單要想訓練的流程，還得手把手一步一步帶個好幾次，最後卻只能讓他去作曾經帶過的工作。
這樣子的人，可能永遠無法往程式更高的境界走。可能一直滿足於自己又拼出了多少功能而已。除了對他們這輩子有限的成就感到可惜，也為自己的時間精力白白浪費在這種人身上感到悲哀…
