1.擁抱即時原則
如果有什麼事在五分鐘內可以完成，就立刻完成它。
這聽來像個偷懶的選擇，但推遲事情實際上需要許多額外的工作。它得寫下這個任務，然後追蹤並且跟其他的事項排定優先權。你可能會在實際上做完之前想起它很多次，而且你還必須搞清楚當你寫下它的時候是什麼意思，並且想辦法回到當下的思考狀態。
對於小任務來說這並不值得。
取而代之的，直接完成它。在你已經想到這個問題時就當下修掉，這比較快、簡單而且省掉你跟一堆越來越長的代辦事項清單搏鬥的苦惱。
如果有什麼事在五分鐘內可以完成，就立刻完成它。
這聽來像個偷懶的選擇，但推遲事情實際上需要許多額外的工作。它得寫下這個任務，然後追蹤並且跟其他的事項排定優先權。你可能會在實際上做完之前想起它很多次，而且你還必須搞清楚當你寫下它的時候是什麼意思，並且想辦法回到當下的思考狀態。
對於小任務來說這並不值得。
取而代之的，直接完成它。在你已經想到這個問題時就當下修掉，這比較快、簡單而且省掉你跟一堆越來越長的代辦事項清單搏鬥的苦惱。
2.解決病因而不是症狀
不要只是解決問題。解決讓問題發生的流程，這樣同樣的問題就不會再度發生。別只把bug當作討厭鬼，要把它當作是加強流程與增進程式碼品質的機會。
當美術告訴你碰到了一個"編譯單元錯誤"的訊息時，不要只是丟一個對話框告訴他"這是因為你有兩個node是同一個名字，這樣不合法"。最起碼要把錯誤訊息改成"編譯單元錯誤：bed。兩個node有同樣的名稱：pillow。其中一個需改名以確保名稱唯一"。要做得更好的話，在exporter或tool裡作修改，讓美術無法建立有兩個同樣名稱的node。
如果你發現當下這個錯誤可能在assert中攔截的話，就加入這個assert，這樣下次錯誤再度發生時就可以找到了。
如果有人問"我要如何設定動畫壓縮?"，不要只是跟他說而已，要同時寫下簡短的文字說明其原哩，並且加到文件中。
這樣子，你不會只是補破網，而是積極的改善事情。這不只是取悅那些發生問題後來找你的人，同時也是讓你的工作感覺更有意義。
3.當電腦運轉的時候，試著不要中斷注意力
程式工作充滿了許多奇怪的短暫停頓：程式碼在編譯、console重開機、關卡讀取中、client端連結中等等。
理想狀態中這些停頓都將不存在，盡你所能的去消滅掉他們，讓code build快一點、即時重新讀取資料與script、做個工具可以快速設定一大堆PS3來做網路測試等等。
但是即使做了再好的努力，依然有些時間空檔會留下來，問題在於我們如何利用它。誘惑在於我們會去短暫地從編寫程式中休息，轉而去檢查一下mail、回應一下Skype、讀兩段有興趣的文章、更新twitter狀態等。
對我來說，這些不斷的心理狀態切換是生產力的阻力，它們使得保持在心流狀態(flow)變成是不可能的事。
這些簡短的瀏覽並不會真正讓你放鬆，當你一邊瞄個兩眼看另一個螢幕的進度條一邊讀個兩篇網頁並不會真的讓你的心神平靜下來。正好相反，這會比你一直保持在”禪”狀態中更加有壓力。找個時間真正休息下來會比上百個短暫的休息來的更好。
為了同時保持生產力與心理上的平靜，我做了個有意識的努力使得"電腦工作時"我依然能專注在目前的問題上。我有個另外的不受IDE實行時中斷的文字編輯器，讓我可以作些相關的工作，像是：
- 加上文件說明
- 重構與程式碼review
- 計畫下一個要實做的步驟
- 寫測試系統用的script
這依然是個對抗上網誘惑的無止境戰鬥，但我發現當我管好自己保持專心時，我會同時更有效率也更加放鬆。
4.比你認為需要的更加多使用版本控制系統
版本控制不是只用在程式碼。現代的分散式版本控制系統像是Mercurial與Git，要建立一個原始資料庫然後push到server以便備份或共享實在是簡單的要死。
你有文字編輯器/IDE的組態檔和設定檔吧？把它們放到版本控制中，這樣就可以很容易的在不同機器中使用同一個設定。這些檔案需要被安裝到特定的位置的話，把處理安裝程序的script連同它們都放到版本控制中吧。
你是否有使用第三方的程式庫像是zlib、LuaJIT或stb_vorbis？把他們放到版本控制中。這樣一來如果你有對他們作任何的更動（修bug、修掉warning、平台修改或是自己作效能提昇）就可以很明確的知道你改了些什麼。如果有新版本的程式庫釋出，你可以用版本控制系統來比對哪些部份有修改，並且將它合併到你的版本中。
API有提供範例程式嗎？在你開始把玩它之前先放到版本控制中。這樣一來你可以隨時把範例檔恢復到原始的狀態中而不必再次安裝API。而一旦你發現了API的bug時想要重現在一個簡單的範例檔時，可以使用版本控制工具來產生一個給該sample的patch檔附在給API製造商的bug report上。這會讓雙方都會很開心的。
5.監控你的編譯
設定好一個build server好持續的build出在所有平台的所有組態(debug, development, release) 的所有執行檔（引擎、工具、exporter等），這樣你就可以儘快知道哪邊有問題了。當場就修好問題比起兩個月後才作好多了。
Build server不必要弄得很複雜，重要的是要有而不是弄得很花俏。如果你沒有時間作進階的處理，寫個script去compile所有的東西然後回報也行。你可以有時間再去加強它。
對資料內容也這樣做。寫個script讀取所有的關卡並產生所有的單位，
使用對你而言最好的回報工具。我們內部是用Skype作為即時通訊系統，所以對我們來說即實用Skype回報build壞了是很合理的。如果用e-mail或是IRC對你來說比較好，就改用它們吧。
對資料內容也這樣做。寫個script讀取所有的關卡並產生所有的單位，
使用對你而言最好的回報工具。我們內部是用Skype作為即時通訊系統，所以對我們來說即實用Skype回報build壞了是很合理的。如果用e-mail或是IRC對你來說比較好，就改用它們吧。
