為什么打斷 15 分鐘的代價是 1 個小時

>>> 技術話題—商業文明的嶄新時代 >>>

簡體傳統

過去一個月里我一直在為生產力的問題奮斗。整體而言感覺自己產出不夠多。我開始探索原因，找出工作時發生的狀況，或者到底是什么阻止了我在項目上有不錯的進展。這項研究最終富有成果。

mo·men·tum (mōˈmen(t)əm,məˈmen(t)əm/)動量，動力，勢頭

一個移動中物體的動力的總量，通過該物體的質量與速度之乘積來測量。

當我坐下來準備編寫項目代碼，是無法直接進入狀態的。如果是從項目起始點開始，或從工作日開始，我不得不先加載很多數據到大腦里。你可以把它想像為大腦內存。

這個部分是用什么語言寫的？
該語言的所有語法
目前手頭項目的目的是什么？
這是解決這個問題的有效方法嗎？
這會導致我以后欠下技術債嗎？
這會影響到應用的另一個部分嗎？

如果你是領導，你還必須考慮這些：

這是能賺錢/好的商業決策嗎？
這是可以復用的嗎？
這真的就是最好的用戶體驗嗎？

這些都還只是元細節，都還不涉及手邊具體的問題。實際情況是，你遇到的有數學、標準的編程實踐、業務邏輯、數據庫查詢、插件的細微差別、自己的代碼細節以及更多的問題。

最佳的動量是以伏筆的形式到來的。即你已經在腦海中勾畫出了短期的路線圖，并且已經準備好為接下來的兩個步驟編碼。我最喜歡的方式就是以注釋的方式來提早寫好步驟。

//鏈接數據庫
//獲取客戶端信息
//創建數據緩存
//連接到UPS的接口
//使用數據包來創建一個預測
//驗證預測
//生成傳輸標簽
//使用 graphicsmagick（此處原文中筆誤寫成了graphicsmagik）轉換原始數據為PDF
//整合多個 PDF 為一個單獨的頁面
//呈現 PDF 給用戶

我喜歡類似這樣的清單。它具有挑戰性并讓你有事可期待。當你知道如何去完成每一項，你的動量會成指數級增加。這些任務被你越發快速、高效地完成，超過你不寫清單時的表現。

注：要想直奔主題地考慮可以在哪兒寫下上面的清單，你必須至少已經在腦海中完成了任務中基本的部分。

打破動量

有三種情況可以徹底毀掉你的動量。它們可以讓你完成任務的能力降低兩三倍。

有些事情沒有按照預期進展。
有人干擾了你（比如：郵件、Skype、消息、同事、社交網站）
時間到了（回家，睡覺）

有些事情沒有按照預期進展

這一點甚是煩人，但是卻非常常見。想象一下，你以為知道該如何使用 UPS 的接口，但是它莫名其妙地就是不管用。你之前也曾使用過，非常清楚它應當是如何操作的，然而當你測試的時候，出現一片空白。假如你足夠幸運可以得到明確的錯誤消息反饋，通常還不會失去太多的動量。不然，你就會相當受挫。此時你有如下幾個選擇：

尋找一些正常運行的代碼然后對比差異
在 Google 上搜尋
在 Stackoverflow 上提問
跟一個朋友咨詢，去騷擾他們
發布一個問題到 Github，期待有人盡快回復
想出一個新辦法

所有這些都只是在徹底毀掉你已有的工作動量。忘掉那個清單，忘掉你要盡快解決掉它，從現在開始你必須全身貫注到這些從未計劃會消耗超過兩分鐘的隨機事件上。

對于此，我的解決方案是積累經驗。你擁有的經驗越多，解決的問題越多，你不能解決問題的機會就少。學會 debug！經驗同樣能教你如何更有效地Google，以及更快速地查找答案。

打斷/中斷

各種打斷是最大的時間殺手。你的老板、同事、會議，都特別礙事。他們可以讓你無法集中精力，并且你離開手頭項目的每一分鐘其實等同于失去三個小時的動量。

假如你現在正準備編寫一個循環來檢查所有數據包的大小，內容以及或許還要計算一下體積重量。然后有人問你：“你能快點從數據庫抓取一下 XYZ 給我嗎？” 我會回答說“好”然后拿到這個數據。但這估計會花掉 4 分鐘，因為可能我需要查找一下 SQL 命令或者回憶一下有些數據表的結構。謹記對于任何項目而言（甚至是這個半路殺進來的任務）我都需要加載如上所述的整個清單。此時，第一個項目的大腦內存正在衰減。