最近其實滿常聽到同圈的人提到自身經驗，認為程式設計師一天能實際專注並產出的時間，六小時就不多就是「極限」了。若超過六小時，再多的時間都只是沒有效率的狀態去強逼自己產出的。這是一個很有趣的議題和數據，不確定有沒有論文專門在研究這方面的議題，之後有時間可以來找找看，滿好奇有沒有實驗統計出來有效率的時間是接近六小時的，也滿想知道這方面的議題會怎麼設計實驗。嗯，話題跑遠了。總之，今天想要聊的就是這類議題，也就是調整好自身狀況，並在最有效率的時間工作，或是讓自己能工作的時間保持在有效率的狀態。

大家也常講，程式設計師最崩潰的事情，就是在思考時被打斷，這其中不只包含 Context Switch 的成本，也包括思路一旦停下來，就只能重新開始，而頻繁地打斷就意味著程式設計師會不斷重複好幾次走過的路，這是一種極大的浪費，甚至會失去在今天抵達終點的機會。所以讓自己預期最能有效率產出的時間不被打斷，就是一件很重要的事情。這部分遠端工作者會比較容易營造不被打擾的環境，但若是在公司上班，尤其是開放式工作空間的程式設計師就必須要好好和團隊與組織溝通。

比較常聽到的做法，就是每天固定某段時間，可能 1 ~ 2 小時，若是沒有要緊到「需要當下馬上處理不然公司產品會炸掉導致損失到可能破產程度」的問題（故意不停頓），就不要來打擾。有事情想要傳達，可以多利用 E-Mail 或是 Slack 之類的通訊工具先留言，等閉關時間結束後再回覆。也就是當我們一旦進行閉關後，可能就會連帶把任何通訊工具都關掉，專心面對眼前想解決的問題。

而固定某時段，也是讓大腦與心態習慣：「啊，到了這個時間了，該靜下來解決一個問題了」，就像我現在每天晚上十點一到，就會坐在電腦前面花費兩個小時寫三篇鐵人的文章一樣。一旦固定久了，該時段就很容易成為你的有效率產出的時段。在想要有效率產出前，也可以用點小儀式來宣告。就像是我們在開回顧會議時會有報到活動讓大家轉換心境一樣（可參見《為團隊與組織導入敏捷的經驗分享》 系列文的〈Retrospective 活動〉系列），我們也可以為自己定一個登入儀式，比如說閉目養神 15 分鐘之類的。

而在開始有效率產出前，記得先和團隊交流，暸解當下最需要優先被解決的項目有哪些，哪些是比較適合自己做的。可以依照成本與閉關時間去列個 1 ~ 5 個項目，或是把一個比較需要多天時間解決的項目拆成好幾個段落，至少讓自己每天的有效率時間能做好一件事情，作為一個正面回饋和目標。這部分可能也要經過數次的閉關後，才好聊解自己大致上能解決的數量或程度。以鐵人賽為例，我認為為兩個小時的專注時間，要寫出三篇文章的話，一天文章大概一千字上下就差不多是極限了，所以我每次都以一千字為標準，若寫超過一千字就開始收尾，並且已完成三篇文章為目標。軟體開發上標準可能沒有辦法那麼明確，這部分就要靠經驗去為自己設置停損點與目標大小了。

而在有效率產出時間外，我們可能也會有基本產出的時間，這部分就依照自己當天額外庶務的情況去放鬆發揮。如果是比較需要和其他人討論的產出，也可以在這個時段進行。也可以搭配蕃茄鐘去記錄自己的實際產出時間（包括閉關和正常）、或是各類活動的時間，評估出自己大概一天實際的能投入的時間大概多少，或是保持專注的時間多少是極限等等。為自己進行記錄，然後作出調整。

至於睡眠充足以及水分補充等常識類概念的幫助也不要忽略，尤其是要與人共事的場合，若前一晚還在為不重要的事情熬夜，不但讓自己的產能降低，也是對其他人的不尊重。而在一天的工作時間裡，若是發現自己已經開始無法專注時，寧願出去走走或是小睡一毀，也不要硬撐。學會調整好自身狀況，也是軟體開發很重要的事情。君不見，多少次隔天醒來看向昨晚寫的程式碼，都痛恨自己前一晚為什麼要熬夜工作。