轉載來自：http://www.cnblogs.com/E-star/archive/2012/05/06/2486594.html
摘自上海交大bbs：
奮是基礎，一切的前提
奮之上是忍耐
大部分時候大部分人的“習慣”都是跟“效率”作對的
奮讓你有機會去跟這些習慣做鬥爭
在 ACM 競賽的級別，寫代碼不是在解題，而是實現早已在腦子裏準備好的一個邏輯流程。
這個追求跟大部分沒有訓練過的人的習慣相反，要扭轉這種習慣，第一步可以做嘗試有：
1. 把準備和敲鍵盤分割爲兩個動作。
2. 把敲鍵盤和運行分割爲兩個動作。
3. 編譯錯誤這件事情幾乎總是會發生，但“嘗試”減少編譯錯誤的過程，確實對提高準備
效率很有幫助幫助。
寫程序的 準備->寫代碼->測試 三階段，普通人之間差距最小的就是第二個階段。速度都
是在“短到完全不充分或者長得非常沒建設性”的準備期，以及“沒完沒了地冒出計劃外
BUG 或者遭受?到不行的 Debug 災難”的測試期，被拖慢下來的。
如果你是隊裏的隊員，那麼以下幾點是必須做到的：
1. 敲鍵盤中的任何時候，如果發呆超過三分鐘，說明沒準備好，滾下機器去想清楚。
2. 編譯器告訴你某個變量沒聲明，結果你突然發現不知道應該在哪裏聲明它。這時候同樣
說明準備沒做好（根本就是對象和邏輯都是亂的），滾下機器去想清楚。
3. 爲 ACM 競賽而寫的代碼，不需要 DEBUG 模式。
作爲一種粗略的判斷標準，“一次過 Sample 的概率”是很重要的。好好準備了的程序，
如果經常不能寫好立刻過 Sample，那一定是準備方法有問題。
最後再強調一件事情??發現程序有邏輯錯，或者乾脆算法有遺漏了的情況，彆着急打補
丁。一個工作需要一個補丁，就很有概率需要更多的或者更大的補丁，很多時候你遺漏的
不是一個 Case 而是一類情況、一個大的角度，這種情況只有通過重新檢查算法邏輯或者
實現邏輯才能扭轉過來，拍腦袋打上的補丁只會增加未來差錯的負擔而已。