有时候我就是什么事情都完不成。

当然,我还是来到办公室,转悠转悠,十秒钟查一次邮件,上上网,甚至做些不费脑子的活,比如把美国运通的账单付了。但心思就是回不到写代码上。

这种没有效率的状态时不时就来一回,而且每次往往要持续一两天。但是在我的开发生涯中,有几次甚至好几周都干不成什么事儿。就像他们说的,我不在正轨。我不在状态。我哪里都不对。

每个人都有情绪波动;不过表现上有所差别,有的人轻微,有的人明显一些、甚至不正常。而且这种周期性没有效率的状态看起来的确和低落的情绪有点关系。

这让我想起那些研究人员的话,人基本上控制不了自己吃什么,所以任何控制饮食的举动一定持续不了多久,最后体重总是慢慢悠悠地回到自然状态了。作为软件开发者,或许我真的无法控制什么时候才有效率,只能接受时而干活快、时而干活慢的现实,唯希望平均下来我能写出足够的代码量,既而混口饭吃。

让我抓狂的是,从第一份工作开始我就意识到,作为开发者,通常我每天的有效编码时间在两三个小时左右。我在微软做暑期实习的时候,一个实习生对我说,实际上他每天只是从中午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正在招募译者,点此查看试译活动!