行進中開火(不參與joel-on-software一書的試譯)

有時候我就是什麼事情都完不成。

當然，我還是來到辦公室，轉悠轉悠，十秒鐘查一次郵件，上上網，甚至做些不費腦子的活，比如把美國運通的賬單付了。但心思就是回不到寫程式碼上。

這種沒有效率的狀態時不時就來一回，而且每次往往要持續一兩天。但是在我的開發生涯中，有幾次甚至好幾周都幹不成什麼事兒。就像他們說的，我不在正軌。我不在狀態。我哪裡都不對。

每個人都有情緒波動；不過表現上有所差別，有的人輕微，有的人明顯一些、甚至不正常。而且這種週期性沒有效率的狀態看起來的確和低落的情緒有點關係。

這讓我想起那些研究人員的話，人基本上控制不了自己吃什麼，所以任何控制飲食的舉動一定持續不了多久，最後體重總是慢慢悠悠地回到自然狀態了。作為軟體開發者，或許我真的無法控制什麼時候才有效率，只能接受時而幹活快、時而幹活慢的現實，唯希望平均下來我能寫出足夠的程式碼量，既而混口飯吃。

讓我抓狂的是，從第一份工作開始我就意識到，作為開發者，通常我每天的有效編碼時間在兩三個小時左右。我在微軟做暑期實習的時候，一個實習生對我說，實際上他每天只是從中午12點工作到下午5點。只有5個小時，還要扣掉午飯時間，但他乾的活仍然儘量比平均工作量多很多，所以團隊的人都很喜歡他。我也發現的確是這樣。當看到其他人好像都在非常努力地工作時，我還有點內疚；我每天有兩三個小時高質量工作的時間，但仍然總是團隊中最具生產率的成員之一。這可能也是人件（Peopleware）和極限程式設計（XP）堅決要求取消加班，並將每週的工作時間嚴格限制在40小時的原因吧。既然有把握這麼做，肯定是知道這不會降低團隊的產出。

但讓我擔憂的不是那些“只有”兩小時完成工作的日子，而是什麼都完不成的日子。

這一點我想了很多。我試圖記起職業生涯中出活最多的時候。大概是那時吧——微軟讓我搬進了一間漂亮、豪華的新辦公室，透過大大的落地窗，可以俯瞰開滿櫻花的石砌院落。一切都是那麼愜意。有幾個月我不停的工作，終於打磨出了Excel Basic的規格說明書。用掉的紙張堆起來能有紀念碑那麼高，我描述了規模龐大的物件模型和程式設計環境，其細緻程度讓人難以置信。中間我就未曾停頓過。當我不得不去波士頓參加MacWorld大會的時候，我還帶著膝上型電腦，坐在哈佛商學院舒適的陽臺上為Window類編寫文件呢。

一旦走上正軌，保持起來並不難。很多日子我是這麼過的： (1)開始幹活 (2)查下郵件，上上網，諸如此類 (3) 作出決定，幹活之前還不如先把午飯吃了 (4) 午飯歸來 (5) 查下郵件，上上網，諸如此類 (6)終於下定決心，我得幹活了 (7) 查下郵件，上上網，諸如此類 (8)再一次下定決心，我真得幹活了 (9)啟動該死的編輯器 (10) 不停地編寫程式碼，不知不覺已經晚上7:30了。

第8步和第9步之間似乎有點不對勁，因為我並不是總能跨過這個檻。於我而言，開始幹活就是唯一困難的事兒。因為靜止的物體傾向於繼續靜止。腦子裡有些重的不可思議的東西，壓得我提不起速度，但一旦全速運轉起來，保持下去倒是毫不費力。就像為準備獨自越野旅行而收拾一番的自行車——這個滿是齒輪的東西，當你踩下第一腳時，不知道要花多少力氣；但一旦轉了起來，騎的就像是沒有齒輪的自行車一樣，非常輕鬆。

或許這就是效率的關鍵：只要做起來。結對程式設計能夠奏效，也許就是因為當你和夥伴進行結對程式設計時，你們會強迫彼此做起來。

當我在以色列當傘兵的時候，有位將軍路過，就給我們講了點戰術。他告訴我們，步兵戰中只有一種戰術，那就是“行進中開火”。一邊衝向敵人，一邊開火。火力壓得敵人抬不起頭，他就無法向你開火了。（戰士們喊“掩護我”，就是這個意思。這意味著，“在我跑著衝過街道時，你們向敵人開火，他不得不躲閃，也就不能向我開火了。”這的確管用。）行進使你能夠佔領陣地並接近敵人，擊中目標的可能性也隨之增大。你不前進，敵人就可以弄清形勢，這可不是好事。你不開火，敵人就會向你開火，束縛你的行動。

很長時間，我一直記著這個戰術。我注意到，幾乎各種軍事策略——從空軍的空戰，到大規模海軍演習——都是基於行進中開火戰術。我又用了15年才意識到，這一原則也可以用於生活中，指導你做事。你每天都要前進一小步。程式碼很爛，很多bug，這不是問題。只要你在進步，繼續編寫程式碼並不斷地修復bug，時間就是站在你這邊的。當競爭對手向你開火時，一定要小心。難道他們不是想讓你疲於應付其攻擊而無法前進嗎？

想想微軟提出的各種資料訪問策略的歷史吧。從ODBC、RDO、DAO、ADO和OLEDB，到現在的ADO.NET——全是新的！真的需要這些技術嗎？是不是設計組太無能了，以至於每年都要發明新的資料訪問技術？（實際上，可能真是這樣。）但是，這其實就是掩護火力。除了花時間移植和跟上，競爭對手別無選擇，這樣他們就沒時間編寫新特性。仔細看看軟體領域吧。能做好的公司都是這種——它們很少依賴大公司，也不必將所有的產品週期都用在追趕和重新實現上，或是用在修復僅出現在Windows XP平臺的bug上。而跌倒的是這樣的公司——它們將時間用在了算卦一般地研究微軟的未來方向上。人們開始為.NET而擔心，並決定為.NET重寫整個架構，因為他們認為不得不這麼做。微軟正在向你開火呢，這正是掩護火力，進而它們能進步，而你不能。遊戲就是這麼玩的，寶貝！你要支援Hailstorm嗎？SOAP呢？RDF呢？你支援它是因為客戶需要，還是因為有人在向你開火，你感覺必須作出反應呢？大公司的銷售團隊都懂得掩護火力。他們走到客戶中間，這樣說，“好的，你不必從我們這買。你可以選擇最好的供應商。但是，一定要保證所買產品支援XML/SOAP/CDE/J2EE，否則你將被他們的技術套牢。”之後，當一些小公司再來推銷產品時，聽到的都是聽話的CTO鸚鵡學舌般的叨叨：“你們有J2EE嗎？” 即便真的賺不到什麼錢，這些小公司也不得不將所有的時間都浪費在使用J2EE構建產品上，從而喪失了讓自己脫穎而出的機會。這就像個核取方塊，因為你需要讓核取方塊說你有這種功能，所以實現了這種功能，但該功能可能沒人用，或者沒人需要。這就是掩護火力。

行進中開火，對我們這種小公司而言，意味著兩件事：必須讓時間站在你這邊，而且每天都要有所進步。這樣你遲早會贏的。昨天我忙了一天，只是讓FogBUGZ的配色方案好看了點。這也可以。一切都在朝好的方面發展。每一天，我們的軟體都在越來越好，我們的客戶也越來越多，這才是最重要的。在公司達到Oracle的規模之前，沒必要考慮什麼巨集偉戰略。我們只需要每天上午來到辦公室，不管怎麼說，開啟編輯器。

原文：Fire And Motion

原文作者：Stack Overflow創始人Joel Spolsky背景介紹

Joel On Software正在招募譯者，點此檢視試譯活動!