程式設計師 告訴他們被打斷的真實代價

　　對程式設計師來說，打斷是低效率的最大原因之一。說實話，這種情況可能對任何人來說都是這樣，只是對程式設計師而言相更糟糕一些。我舉個例子來解釋吧，比如有一個做銷售的人，他的大部分時間可能就花在接打電話或者在不同會議之間交替的途中了。在某一個會議上，或者某一次會議之前的回顧過程中，對銷售人員來說，一次中斷的代價意味著他花在處理被打斷上的時間。比如一次搖頭，或者“我剛講到哪兒了？噢，我想起來了。”

　　再比如一個經理，他的一天總是充滿了一系列沒完沒了的中斷。在管理層面，我發現到了中午卻仍然沒有做完計劃中的第一件事是很常見的。Paul Graham寫過一篇非常好的文章，是關於管理者和他所說的“製作者(maker)”的每一天的不同本質。而程式設計師，很顯然的就包括在“製作者”這個分類中。

　　中斷對於一個程式設計師來說是如此的不同。你坐在電腦前，現在有十二個呼叫在呼叫棧中。一個顯示器上是精心挑選的輸入集，它們將會輸入到負責生成內容的一個複雜表格中。另一個顯示器上有著舒服的暗色調主題的IDE，偵錯程式的當前行泛著憤怒的黃光。你為了這一刻已經工作了50分鐘了——終於輸入了正確的值；搞明白了事件觸發的順序；成功通過了正好數量的foreach和while迴圈，每一個都花了個好幾分鐘時間；在異常觸發前設定好斷點，使得你跳轉到程式碼庫另一側的一些處理程式上。就在現在，這個非常時刻，你意識到了為什麼Orders集合中有22個物品，你搞明白了_underbilledCustomerCount 值是什麼，你還匆匆忙忙寫下”8xZ204330Kd”這個字串，因為它是一個從一些隨機數和全域性唯一標示符(GUID)的組合自動生成的驗證碼，你還沒搞懂GUID，但是你也不想去搞懂它，因為你只需要知道這個字串是什麼就可以了。現在這個時候，你已經完全陶醉了，因為你馬上就要揭開在這個第三方庫函式呼叫中到底是什麼引發了一個未將物件引用設定到物件的例項的異常(null reference exception)，你非常確定那就是 ——

　　“嗨！！！事情做得怎麼樣了？對了，你也覺得客戶訂單崩潰的事情很糟糕吧？或許你能給我一個解決它的預計完成時間(ETA)？”

　　臥槽！！！！

　　專案主管剛剛在你即將按下下一條指令時，在你打算使用“跳過”而不是“進入”時嚇了你一跳。他嘮嘮叨叨的講述自己或者是客戶或者是其他什麼事情的重要性，反正你是沒在聽，因為你一邊在極力控制著失去所有除錯的前後聯絡的暴怒，一邊在提前思考怎麼樣再能回到二十分鐘前的那個狀態。但這些都無濟於事，專案主管的老大看見他正在跟你討論，也走了過來。現在你的鄰桌上爆發了一場的關於Initrode賬戶的討論，十分吵鬧，並充斥著莫名其妙的buzzword bingo（譯者注：一種遊戲）和一些關於“在球門區處理比賽”的體育隱喻等等。當吵鬧結束的時候，你在六西格瑪（譯者注：一種商業管理戰略，詳見[維基百科]維基百科）體制中黑帶三段的手下乖乖就範。你知道自己得點一個披薩，在晚上7點大家都走了再來做這件事兒，這樣才能夠安安靜靜的工作。你現在能做的只有搖搖頭，然後想著“ 8xZ204330Kd 到底代表著什麼？我為什麼要寫下這東西？”

　　但接下來才是真正雪上加霜的時刻。當你嘗試著向向專案主管解釋剛剛的舉動對你的工作成果造成多了多麼毀滅性的破壞時，他哼你一聲並告訴你不要這麼聳人聽聞。他也總是在想，為什麼程式設計師總是跟女主演一樣過於戲劇性。同樣，不管你多少次說明，你的非技術的同伴也搞不懂你的苦衷。試想你的工作差不多就是整天走來走去，不停要求別人更新進度以及接受來自上層的同樣的要求，理解程式設計師們風格迥異的工作模式的確不是易事。以上兩種角色我都曾扮演過，而現在我每天用相當大一部分時間做策劃和管理活動。我必須抑制住不時的走到我的隊伍所在的地方並打斷他們來獲得一丁點資訊的衝動，即使我能用這些資訊發一封郵件，或者將他們加到已解決事件列表中。專案管理，或是其他管理者們，都有十分現實的問題，其中許多涉及到試圖給合作伙伴，客戶或內部員工提供及時的支援。在他們看來，事務或者問題都是可以被打斷的。

　　好了，別擔心，我想我有一個方法能讓你能夠向他們證明，跟他們的工作相比，一箇中斷對於你的工作成果有多麼毀滅性的影響。換句話說，能夠讓別人理解對於你來說，一箇中斷不僅僅是一個馬上就能補回來的耽擱這麼簡單，而是毀掉了你直到那個時間點之前的所有工作。以下就是該方法。

　　邀請你的專案管理，經理，銷售或者其他什麼人，讓他們坐在凳子上，然後告訴他們你的小幽默。開啟記事本軟體，輸入一串3到4位的數字，就像這樣：

123
234
345
543
432
321
999
888
777

　　現在，告訴他們將這些數字用心算加起來。只能盯著螢幕或者在口中默唸，不能寫下任何東西，也不能輸入任何內容。他可能會笑你，但你可能用一頓午飯賭他五分鐘之內連僅僅是得到一個答案都無法完成。他可能接著笑話你並且開始嘗試。

　　你只需雙手抱頭愜意地坐下來，給他半分鐘或者更長的時間，慢慢聽他念念有詞地計算。然後拿起你的手機打給他的辦公室。如果他無視這個電話，開口問他是否準備接這個電話，因為這通電話有可能很重要。他可能會嘀咕一會兒，不得不重頭開始。

　　再給他30秒或者更多時間，跟他說：“嗯，比想象的難是吧。你現在加到哪兒了？知道我經常想到哪個數字嗎？333。這數兒挺有意思。噢，也有可能是221。也可能是加起來是9365的一些數。瞧瞧這些數字，你說是吧？哎喲，說了些廢話，不好意思，你在集中注意力啊。我閉嘴我閉嘴。”

　　再等一分鐘。拿出你的電話，假裝對著沒有人聽的話筒大聲的說話，模擬一通電話。開始背誦想象出來的電話號碼，裝出一副羞怯和歉意的表情。

　　一分鐘後，突然告訴他今天你的工作狀態非常低落，問問他是否還要讓你將那三樣東西，以及四五件其他東西加到六七個即將到來的業績展示的幻燈片上。噢，天吶，你又提到數字了，你個壞人。

　　最後給他一分鐘。告訴他只剩下20秒了，或許是30秒，也可能是25秒。不管是多少，他現在正是關鍵時刻。哈哈好吧，你知道他會失敗的。那就提前感謝他請你吃午餐吧。但是，如果他答應以後當你程式設計 — 事實上就像是整天在腦子裡追蹤一連串數字 — 的時候，不再不停的對你做剛剛你對他所做的那些事情，就讓他留著那午餐錢吧。

　　原文連結： DaedTech   翻譯： 伯樂線上 - Hacker_YHJ