转:开火,移动-大神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,谁认识?