Nio 的個人網站

這是Nio的個人記事網站,同時也兼作開發技術嘗試。如果在觀看的時候發現有錯誤,請不吝動手告訴我
剪貼簿   >>  其他
邊開火邊移動

原文出處:
http://chinesetrad.joelonsoftware.com/Articles/FireAndMotion.html

邊開火邊移動


作者: 周思博 (Joel Spolsky)
譯: Paul May 梅普華 
編輯: Ing Yong Chuan 吳勇撰 
2002-06-01

我總會有時候什麼事都做不了.

我當然還是會去上班, 不過卻是到處閒逛, 每10秒就收一次信, 逛逛網站, 甚至做些付信用卡帳單之類不用動腦的事. 什麼都做就是沒法子進入狀況回來寫程式.

這種不事生產的毛病通常一發作就是一兩天. 不過在我職場生涯中也曾有過幾個星期沒有產出的情況 . 就像別人所說的一樣, 我沒有進入狀況. 我定不下心來. 我不知道自己在幹啥.

每個人的情緒都會波動; 有些人波動較少, 而其他人會比較明顯甚至完全失常. 不過無生產力的時期似乎和憂鬱情緒有關.

這讓我想到, 有些研究者聲稱人基本上是無法控制自己吃什麼, 因此節食絕對不可能持久, 最後一定會回到自然的體重. 或許對身為軟體開發人員的我來說, 同樣無法控制自己的生產力, 只能接受自己有時快有時慢, 並且祈禱平均起來的生產力還能讓自己不會失業.


真讓我受不了的是, 從我做開發工作以來, 平均每天只有兩三個小時能有效率地寫出程式. 當我暑假在微軟實習時, 另一個實習生告訴我他每天只有12點到5點在做事. 做五個小時(還要扣掉午餐時間)的事, 而他的小組卻很崇拜他, 因為他的成果還是比一般人多很多. 我也發現一樣的情形. 當我發現大家都非常努力工作, 而每天只有兩三個小時效率的我卻還是組裡產出最多的人, 不禁令人有點內疚. 這或許就是Peopleware和極限程式作業(XP, eXtreme Programming)緊持不加班而且每週只應工作40小時的原因吧, 他們很確定這樣並不會降低團隊的效率.

不過一天"只有"兩三小時有工作並不是問題, 真正困擾我的是那些什麼都沒做的日子.

這件事我想了又想. 我嘗試回想我職場生涯中最有效率的時候. 極可能是在微軟把我放到一間漂亮豪華的新辦公室, 裡頭有著如畫般的大片窗景(美麗的石頭庭園, 裡面滿是盛開的櫻桃樹). 那時候每件事都很順利. 在幾個月內我馬不停蹄地寫出Excel Basic的詳細規格--非常厚的一份文件,鉅細糜遺地敘述一個龐大的物件模型和程式開發環境. 過程中完全沒有停頓. 有一次不得不去波士頓參加MacWorld, 我還是帶著手提電腦坐在哈佛商學院的漂亮陽台上, 繼續寫著視窗類別的文件.

當你進入狀況後, 要繼續維持並不算太難. 我的一天通常都是這樣子的: (1) 上班 (2) 看信看網頁等等 (3) 決定應該吃過午飯後再做事 (4) 吃完午飯回來 (5) 看信看網頁等等 (6) 終於決心該開始幹活 (7) 看信看網頁等等 (8) 再度下定決心真的該開始做事 (9) 把該死的編輯器叫出來然後 (10) 不斷地寫程式直到突然發現已經下午7點半了.

第8步和第9步之間似乎有點問題, 因為我不是每次都能順利跨越鴻溝.

對我來說, 要開始本身就是唯一的難題. 靜者恒靜. 我腦袋裡有些東西重得不得了, 很難很難加速, 不過一旦全速運轉就不必費心維持. 就像要騎車來一趟橫跨美國的自助腳踏車旅行一樣 -- 當你騎上車要開始時, 根本無法想像要花多少力氣, 不過一旦開始騎就發現實在是輕而易舉.

或許這就是生產力的重點: 開始做吧. 或許 配對程式作業所以有效, 是因為把兩個人排在一起作業, 自然會強迫彼此開始.


當我還在以色列當傘兵時, 有位路過的將軍給我們講了一小段關於策略的課. 他告訴我們, 在步兵作戰時只有一種策略: 邊開火邊移動. 你要一邊開火一邊朝敵人挺進. 開火讓敵人抬不起頭, 不能向你開火. (這就是士兵喊"掩護我"的意思. 也就是說"對敵人開火逼他低頭, 這樣我衝過街時敵人就不能向我開火" 這招的確有用.)  移動讓你攻佔地盤並且更逼近敵人, 這時候射擊更容易打中目標. 如果你不移動, 敵人就能控制局勢, 這可不怎麼好. 另外如果你不開火, 敵人就會對你開火把你釘在原地.

這件事我一直記得. 我也注意到由空中纏鬥到大規模的海軍演習, 幾乎所有軍事策略都是由邊開火邊移動的概念延生的. 我又花了15年才瞭解這也是在生活中成功的方法. 每天你都得前進一點點. 你的程式不好有錯還是沒人要, 這全都沒關係. 只要你一直進行, 持續的寫程式並修正錯誤, 時間就會站在你這邊. 當競爭者對你開火的時候要注意. 他們可能只是想逼你忙著應付, 讓你不能繼續前進.

想想看微軟所推出資料存取策略的歷史吧. ODBC, RDO, DAO, ADO, OLEDB, 還有最新的ADO.NET - 全部都是新出的! 難道這些技術都是非要不可的嗎? 還是一個年年都在重新發明資料存取的無能設計團隊的傑作呢? (這很可能是真正的答案.) 不過最終的結果卻剛好成為火力掩護. 它讓競爭者別無選擇, 只能用盡所有時間進行移植和昇級, 沒有時間去寫新功能. 仔細看看軟體業界. 成功的公司對大公司的依賴最少, 不需要花所有工夫追隨並重新實作, 然後去修那些只出現在Windows XP上的問題. 而跌跌撞撞的公司都花太多時間去揣測微軟未來的方向. 大家都擔心.NET的出現, 認為有絕對必要所以決定針對.NET重寫整個架構. 事實上微軟是在對你開火, 而且只是讓他們前進並阻礙你們的掩護火力, 因為這就是遊戲規則, 朋友. 你想支援Hailstorm嗎? SOAP呢?RDF怎麼樣?  你支援這些東西是因為客戶需要? 還是因為有人對你開火而覺得應該有所反應呢? 大公司的業務團隊很瞭解火力掩護這一套. 他們會去跟客戶說"沒錯, 你不一定要買我們的東西. 要買就要買最好的. 不過記得你買的產品一定要支援(XML /SOAP / CDE / J2EE), 否則你就會被綁住了." 然後當小公司試圖接觸這個客戶時, 這個聽話的技術總監就會像鸚鵡一樣說"你們支援J2EE嗎?" 儘管J2EE不會真正帶來收入, 他們還是得耗盡所有的時間加上J2EE, 結果完全沒機會讓產品產生區別. 這是個勾選項目 -- 會去做只是因為需要有個項目打勾表示你也有, 不過沒有人會用也沒有人需要. 而這就是掩護火力.

對我們這種小公司來說, 邊開火邊移動有兩個意義. 你必須爭取時間, 另外每天都得要前進. 你遲早會贏的. 我昨天整天只是把FogBUGZ的配色改善了一點點. 這並不要緊. 東西會愈來愈好. 我們的軟體每天每天都會變得更好, 而且客戶會愈來愈多, 這就夠了. 在我們變成Oracle這種規模的公司前都不用管什麼偉大的策略. 我們只要每天早上來公司, 想辦法要自己打開編輯器就好了.