2009年6月的一天，我在甲方辦公室加班調試程序，筆記本的屏幕只有12英寸，我得不停地在調試器和編輯器之間切換，觀察斷點的執行情況，發現代碼中的問題。在那一刻，我突然覺得所做的完全是低水平重復工作。
        1. 對業務流程不熟悉，對自己的代碼不熟悉，編譯運行后不能預測結果。
        2. 做管理軟件，重復性工作太多。
        3. 技術視野有限，不能從一個更廣的角度去看待問題。
        對于第一個問題，首要要求在寫完代碼后做review，把代碼詳細讀一遍想一遍，確認無誤后才編譯。review要隨時地做，寫完一個函數完成一個功能塊，都要檢查，想一想這段代碼在整個業務流程中的位置。對代碼做到心中有數，而不至于不停的開調試器（調試器是一個效率低下的緣由之一）。
       重復性工作多，這個是管理軟件固有屬性，能否將重復性的工作抽離出來？在之前的項目中，做了很多這方面的嘗試。有一定成效。但另一方面，由于經驗不足，強扭地將一些個性化的東西抽離出來，最后代碼組織結構混亂。要達到重用，有很多條路可以達到，但由于技術的積累不夠，看到一條路就以為這條路是最好的，一往無前地闖過去。其實還有很多更好的選擇，只是因為技術積累不夠，而工期緊張，沒得選了。
       視野有限，所看到僅僅是所寫的，而不能引發更加廣度的聯想。比如說在asp.net中的master頁面，自定義控件，管理軟件三層架構的優勢，mvc等等。沒有深刻地了解和實際的體驗，在項目中自然無法聯想到。所以只能做一些簡單的重復工作。