轉：開火,移動-大神Joel 也浮躁

http://www.ituring.com.cn/article/18728

2002 年 一月六日 星期日

有時候我就是不能靜下心來幹活。

沒錯，我進了辦公室，但我只是到處瞎晃悠，每隔十秒就檢查一下email，看網頁，甚至幹點不走腦子的活，比如支付美國快遞的賬單。但我就是不能專心寫代碼。

面對這種毫無成果可言的狀態，我的鬥爭一般會持續一到兩天。但在我做開發的職業生涯裡，有那麼幾次我幾個禮拜也寫不出來一行代碼。就像他們說的，我不在狀態，我迷迷糊糊，我整天都魂不守舍。

每個人都會有情緒低穀；有些人比較淺，而另外一些人可能會比較深，甚至深不見底直至生活不能自理。這種失力期看起來的確和悲觀失望的情緒多少有些關聯。

這讓我想起了那些專家學者，他們說，人基本上控制不了自己吃什麼，所以那些所謂的節食只能堅持一段時間，然後他們的體重就又晃晃悠悠地回到自然狀態上了。作為一名軟體開發人員，可能我真的控制不了自己什麼時候比較有效率，只能接受高速行進中出現的低速期，並希望我寫出來的程式碼數平均下來能讓老闆滿意。

讓我受不了的是平均一天下來我也就有兩三個小時能好好地寫點代碼，這是我在幹第一份開發工作時意識到的。當年我在微軟做暑期實習，跟我一起實習的一哥們告訴我，他實際上每天只在12點到5點之間工作。扣掉午餐時間是4個小時，可這樣他的團隊還是很喜歡他，因為他比平均水平做得還多很多。我也發現了這種情況。在我看到大家工作都那麼努力時，會覺得有點愧疚，可即便我一天只有兩三個小時的工作能投入，仍然總能成為團隊裡生產率最高的成員之一。這可能是人件（Peopleware） 和 敏捷編程（XP）堅持要消滅加班，把每周的工作時間嚴格控制在40個小時的原因，他們非常清楚這樣不會影響團隊的產出。

但不是那些我“只”能工作兩三個小時的日子在困擾我，而是那些我什麼也幹不了的日子。

關於這個問題我想了很多。我盡量想起自己職業生涯裡工作效率最高的那段時間。大概是在微軟的時候，那時候我應該剛搬進富麗堂皇的新辦公室，特帶勁的大玻璃窗，窗外是櫻花盛開的石頭院落，風景如畫啊！一切，都是那麼的 美好！有那麼幾個月的時間，我幾乎是一氣呵成地把Excel Basic詳細設計說明書給搞出來了，那可是摞起來跟小山一樣高的一堆紙啊，裡面充斥著各種難以置信的細節，楞是把一個巨大的物件模型和編程環境給講清楚了。當我不得不去波士頓參加第一屆MacWorld 大會的時候，我還帶上了筆記本，還在HBS 1 宜人的陽台上寫Window類的文檔呢。

1 哈佛商學院

一旦進入狀態，保持起來並不難。我的一天經常是這樣度過的：(1) 幹活 (2) 檢查 email, 看網頁, 等等. (3) 決定在接著幹活前先把午餐用了 (4) 用膳歸來 (5) 檢查 email, 看網頁, 等等 (6) 下定決心必須開始幹活了 (7) 檢查 email, 看網頁, 等等 (8) 再次下定決心我必須真的開始幹活了 (9) 開啟該死的編輯器，然後 (10) 一直寫代碼，一抬頭髮現已經晚上7點半了。

在第八步和第九步之間貌似有個bug，因為有時候我邁不過去這個檻兒。對於我來說，唯一困難的就是啟動。一個處於空閑狀態的對象傾向於保持閒置狀態。我的腦子裡有某種不可承受之重，壓得我提不起速，但一旦跨過去了，全速前進的狀態保持起來幾乎不費吹灰之力。就好像你整裝待發，要騎車做自助長途旅行，在第一腳蹬下去之前，你很難想象要付出多少努力才能讓它們轉起來，但一旦轉起來了，感覺蹬著跟什麼也沒有似的輕鬆。

可能這就是生產率的關鍵：只要走起來就行。結對程式設計之所以管用可能就是因為你跟哥們約好了結對程式設計的時間，就得互相督促著對方走起來。

我還在以色列當傘兵那會，一次有位將軍順道過來給我們講戰略。他說步兵打仗的時候只有一個策略：開火和移動。邊朝敵人移動邊開火。用火力壓制住他，讓他不能抬頭，他就不能對你開火。（士兵們喊“掩護我”時就是這個意思，“看這，朝敵人開火，壓制住他，這樣我跑過街道時他就不能打我了“這辦法管用）。藉助移動可以佔領更多領土，更接近敵人，也更有可能擊中目標。如果你不動，敵人就會取得決定權，那可不是什麼好事兒。如果你不開火，敵人就會朝你開火，牽制住你。

我對此仍然記憶猶新。我注意到，不論是空軍的空中格鬥還是海軍的大規模演戲，幾乎每種軍事策略都是從開火，移動的思想演化而來的。又過了十五年我才意識到，開火，移動的原則還是指導我們把日常生活中的事情搞定的原則。不積跬步，無以至千裡。關鍵是必須天天向上。代碼漏洞百出沒關係，代碼沒人要也沒關係。如果你能堅持向前推進，堅持編碼，堅持解決bug，時間就會把成功帶到你的面前。競爭者朝你開火時你要當心。他們是不是想迫使你疲於應付，這樣你就無法取得進展了？

想想微軟搞出來的資料存取原則發展曆史。ODBC, RDO, DAO, ADO, OLEDB, 現在是 ADO.NET-全是新花樣！這些技術真有必要嗎？是不是因為設計團隊的無能才導致每年都要重新發明資料訪問技術？（實際上有可能）。但最終效果是形成火力掩護。競爭者除了移植和跟進之外別無選擇，這些就把他們所有時間都耗光了，根本就不容他們花時間實現新功能。仔細看看軟體界的風景。那些做得好的公司對大公司的依賴程度都低，不用把自己的時間全部花在跟進、重新實現和修改bug上，而且在Windows XP上做的工作只在XP上管用，新版Windows出來還得接著折騰。那些在生存線上掙紮的公司在讀茶根占卜2微軟未來方向上花的時間太多了。人們開始對.NET感到憂心，決定為.NET重寫整個架構，原因居然是他們覺得自己必須這麼幹。微軟在朝你開槍呢，而且那隻是火力掩護，這樣他們就可以在壓制住你的同時自己朝前跑了，因為遊戲就是這麼玩的。你準備支援Hailstorm? SOAP? RDF?你支援它是因為客戶需要嗎，還是因為有人在朝你開火所以你覺得自己必須做出響應？大公司的銷售團隊深諳火力掩護之道。他們去拜訪客戶，跟客戶說，“OK，不用從我們這兒買，從我們最好的代理商那裡買吧。但你一定要保證他們給你提供的產品支援（XML / SOAP / CDE / J2EE），否則你就會失去選擇的自由。”然後當小公司想把東西賣給他們時，聽到的就全是被蠱惑的CTO的鸚鵡學舌“你們有J2EE嗎？”所以小公司就不得不把自己的時間全都浪費在J2EE上，即便這麼幹也不能給他們帶來哪怕是一個單子，他們也沒機會讓自己與眾不同，脫穎而出。這是一個多選框特性，你做它是因為你需要這個來證明你有，但沒有人會用它，或者需要它。就是火力掩護而已。

2 一種傳統的家庭占卜遊戲，通過別人喝剩下的茶葉在杯子裡排列的形狀來占卜。

開火，移動，對於像我們這樣的小公司來說，有兩層含義。你必須讓時間站在你這邊，並且你必須天天向上。你遲早會贏的。我昨天一整天都只是在想辦法讓FogBUGZ 的顏色方案稍微改善一點。時間用得挺值的。它總是變得越來越好了。我們的軟體每天都變得越來越好，並且我們的客戶也越來越多了，這些是最重要的。在我們的公司跟Oracle那麼大之前，我們不用去考慮什麼大戰略。我們要做的就是不管怎樣，在每天早上把編輯器啟動起來。

原文：Fire And Motion
作者：牛人一枚，請見 盼盼姐 力作 Stack Overflow創始人Joel Spolsky背景介紹
下面這個真像Joel Spolsky，誰認識？

本文僅用於學習和交流目的，不代表圖靈社區觀點。非商業轉載請註明作譯者、出處，並保留本文的原始鏈