# 十五、开火与运动
我总会有时候什么事都做不了.
我当然还是会去上班,不过却是到处闲逛,每10秒就收一次信,逛逛网站,甚至做些付信 用卡账单之类不用动脑的事.什么都做就是没法子进入状况回来写程序.
这种不事生产的毛病通常一发作就是一两天.不过在我职场生涯中也曾有过几个星期没有 产出的情况.就像别人所说的一样,我没有进入状况.我定不下心来.我不知道自己在干啥.
每个人的情绪都会波动;有些人波动较少,而其他人会比较明显甚至完全失常.不过无生 产力的时期似乎和忧郁情绪有关.
这让我想到,有些研究者声称人基本上是无法控制自己吃什么,因此节食绝对不可能持久, 最后一定会回到自然的体重.或许对身为软件开发人员的我来说,同样无法控制自己的生 产力,只能接受自己有时快有时慢,并且祈祷平均起来的生产力还能让自己不会失业.
真让我受不了的是,从我做开发工作以来,平均每天只有两三个小时能有效率地写出程序. 当我暑假在微软实习时,另一个实习生告诉我他每天只有12点到5点在做事.做五个小时 (还要扣掉午餐时间)的事,而他的小组却很崇拜他,因为他的成果还是比一般人多很多. 我也发现一样的情形.当我发现大家都非常努力工作,而每天只有两三个小时效率的我却 还是组里产出最多的人,不禁令人有点内疚.这或许就是Peopleware和极限程序作业(XP, eXtreme Programming)紧持不加班而且每周只应工作40小时的原因吧,他们很确定这样并 不会降低团队的效率.
不过一天”只有”两三小时有工作并不是问题,真正困扰我的是那些什么都没做的日子.
这件事我想了又想.我尝试回想我职场生涯中最有效率的时候.极可能是在微软把我放到 一间漂亮豪华的新办公室,里头有着如画般的大片窗景(美丽的石头庭园,里面满是盛开的 櫻桃树).那时候每件事都很顺利.在几个月内我马不停蹄地写出Excel Basic的详细规格 –非常厚的一份文件,巨细糜遗地叙述一个庞大的对象模型和程序开发环境.过程中完全没 有停顿.有一次不得不去波士顿参加MacWorld,我还是带着手提电脑坐在哈佛商学院的漂 亮阳台上,继续写着窗口类别的文件.
当你进入状况后,要继续维持并不算太难.我的一天通常都是这样子的:(1)上班(2)看 信看网页等等(3)决定应该吃过午饭后再做事(4)吃完午饭回来(5)看信看网页等等 (6)终于决心该开始干活(7)看信看网页等等(8)再度下定决心真的该开始做事(9)把 该死的编辑器叫出来然后(10)不断地写程序直到突然发现己经下午7点半了 .
第8步和第9步之间似乎有点问题,因为我不是每次都能顺利跨越鸿沟.bike trip对我来说, 要开始本身就是唯一的难题.静者恒静.我脑袋里有些东西重得不得了,很难很难加速, 不过一旦全速运转就不必费心维持.就像要骑车来一趟横跨美国的自助脚踏车旅行一样– 当你骑上车要开始时,根本无法想象要花多少力气,不过一旦开始骑就发现实在是轻而易举.
或许这就是生产力的重点:开始做吧.或许配对程序作业所以有效,是因为把两个人排在 一起作业,自然会强迫彼此开始.
当我还在以色列当伞兵时,有位路过的将军给我们讲了一小段关于策略的课.他告诉我们, 在步兵作战时只有一种策略:边开火边移动.你要一边开火一边朝敌人挺进.开火让敌人 抬不起头,不能向你开火.(这就是士兵喊”掩护我”的意思.也就是说”对敌人开火逼他低 头,这样我冲过街时敌人就不能向我开火”这招的确有用.)移动让你攻占地盘并且更逼 近敌人,这时候射击更容易打中目标.如果你不移动,敌人就能控制局势,这可不怎么好. 另外如果你不开火,敌人就会对你开火把你钉在原地.
这件事我一直记得.我也注意到由空中缠斗到大规模的海军演习,几乎所有军事策略都是 由边开火边移动的概念延生的.我又花了 15年才了解这也是在生活中成功的方法.每天你 都得前进一点点.你的程序不好有错还是没人要,这全都没关系.只要你一直进行,持续 的写程序并修正错误,时间就会站在你这边.当竞争者对你开火的时候要注意.他们可能 只是想逼你忙着应付,让你不能继续前进.
想想看微软所推出资料存取策略的历史吧.ODBC, RDO, DAO, ADO, OLEDB,还有最新的 ADO.NET -全部都是新出的!难道这些技术都是非要不可的吗?还是一个年年都在重新发 明数据存取的无能设计团队的杰作呢?(这很可能是真正的答案.)不过最终的结果却刚好 成为火力掩护.它让竞争者别无选择,只能用尽所有时间进行移植和升级,没有时间去写 新功能.仔细看看软件业界.成功的公司对大公司的依赖最少,不需要花所有工夫追随并 重新实作,然后去修那些只出现在Windows XP上的问题.而跌跌撞撞的公司都花太多时间 去揣测微软未来的方向.大家都担心.NET的出现,认为有绝对必要所以决定针对.NET重写 整个架构.事实上微软是在对你开火,而且只是让他们前进并阻碍你们的掩护火力,因为 这就是游戏规则,朋友.你想支援Hailstorm吗? SOAP呢? RDF怎么样?你支持这些东西是 因为客户需要?还是因为有人对你开火而觉得应该有所反应呢?大公司的业务团队很了解 火力掩护这一套.他们会去跟客户说”没错,你不一定要买我们的东西.要买就要买最好的. 不过记得你买的产品一定要支持(XML /SOAP / CDE / J2EE),否则你就会被绑住了然后 当小公司试图接触这个客户时,这个听话的技术总监就会像鹦鹉一样说”你们支持J2EE吗?” 尽管J2EE不会真正带来收入,他们还是得耗尽所有的时间加上J2EE,结果完全没机会让产 品产生区别.这是个勾选项目–会去做只是因为需要有个项目打勾表示你也有,不过没 有人会用也没有人需要.而这就是掩护火力.
对我们这种小公司来说,边开火边移动有两个意义.你必须争取时间,另外每天都得 要前进.你迟早会赢的.我昨天整天只是把FogBUGZ的配色改善了一点点.这并不要紧.东 西会愈来愈好.我们的软件每天每天都会变得更好,而且客户会愈来愈多,这就够了.在 我们变成Oracle这种规模的公司前都不用管什么伟大的策略.我们只要每天早上来公司, 想办法要自己打开编辑器就好了.
- 第一部分 位与字节:编程实践点滴
- 一、语言的选择
- 二、深入底层
- 三、joel测试:改进代码的12个步骤
- 四、每一位软件开发人员必须、绝对要至少具备UNICODE 与字符集知识(没有任何例外!)
- 五、轻松写就功能规格说明书 - 第1节:为什么烦心?
- 六、轻松写就功能规格说明书 - 第2节:什么是规格说明书?
- 七、轻松写就功能规格说明书 - 第3节:但是……如何?
- 八、轻松写就功能规格说明书 - 第4节:技巧
- 九、轻松制订软件进度表
- 十、每日连编是朋友
- 十一、难伺候的故障修复
- 十二、软件开发中的5个世界
- 十三、稿纸原型开发
- 十四、不要被太空架构师所吓倒
- 十五、开火与运动
- 十六、人员技能
- 十七、源于计算机学科的三个错误思想
- 十八、二元文化
- 十九、自动获取用户故障报表
- 第二部分 开发人员的管理
- 二十、面试游击指南
- 二十一、重金激励害多利少
- 二十、二不配备测试人员的五个首要(错误)原因
- 二十三、任务换人有害无益
- 二十四、绝不去做的事情,第一部
- 二十五、冰川下的秘密
- 二十六、漏洞抽象定律
- 二十七、程序设计界的LordPalmerston
- 二十八、评测
- 第三部分 Joel对常态问题的遐想
- 二十九、RickChapman解读愚昧
- 三十、在这个国家狗是干什么的? 我们有多么天真?
- 三十一、作为哼哈二将,只管去做事
- 三十二、两个故事
- 三十三、巨无霸麦当劳与天才厨师JamieOliver
- 三十四、没有什么像IT看起来那么简单
- 三十五、提防非自主开发综合症
- 三十六、策略I:BEN&JERRY公司与AMAZON
- 三十七、策略II:鸡与蛋问题
- 三十八、策略III:让我回去!
- 三十九、策略IV:大件与80/20神话
- 四十、策略V:公开源代码的经济因素
- 四十一、墨菲法则肆掠的礼拜
- 四十二、微软公司是如何败北API之战的
- 第四部分 对.NET稍多的评说
- 四十三、微软精神失常了
- 四十四、我们的.NET对策
- 四十五、请问,我可以使用连接程序吗