Fire And Motion(英文原版) [转]

Fire And Motion(英文原版) [转]

By Joel Spolsky
Sunday, January 06, 2002
Printer Friendly Version


Sometimes I just can't get anything done.

Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn't happen.

These bouts of unproductiveness usually last for a day or two. But there have been times in my career as a developer when I went for weeks at a time without being able to get anything done. As they say, I'm not in flow. I'm not in the zone. I'm not anywhere.

Everybody has mood swings; for some people they are mild, for others, they can be more pronounced or even dysfunctional. And the unproductive periods do seem to correlate somewhat with gloomier moods.

It makes me think of those researchers who say that basically people can't control what they eat, so any attempt to diet is bound to be short term and they will always yoyo back to their natural weight. Maybe as a software developer I really can't control when I'm productive, and I just have to take the slow times with the fast times and hope that they average out to enough lines of code to make me employable.

  
What drives me crazy is that ever since my first job I've realized that as a developer, I usually average about two or three hours a day of productive coding. When I had a summer internship at Microsoft, a fellow intern told me he was actually only going into work from 12 to 5 every day. Five hours, minus lunch, and his team loved him because he still managed to get a lot more done than average. I've found the same thing to be true. I feel a little bit guilty when I see how hard everybody else seems to be working, and I get about two or three quality hours in a day, and still I've always been one of the most productive members of the team. That's probably why when Peopleware and XP insist on eliminating overtime and working strictly 40 hour weeks, they do so secure in the knowledge that this won't reduce a team's output.

But it's not the days when I "only" get two hours of work done that worry me. It's the days when I can't do anything.

I've thought about this a lot. I tried to remember the time when I got the most work done in my career. It was probably when Microsoft moved me into a beautiful, plush new office with large picture windows overlooking a pretty stone courtyard full of cherry trees in bloom. Everything was clicking. For months I worked nonstop grinding out the detailed specification for Excel Basic -- a monumental ream of paper going into incredible detail covering a gigantic object model and programming environment. I literally never stopped. When I had to go to Boston for MacWorld I took a laptop with me, and documented the Window class sitting on a pleasant terrace at HBS.

Once you get into flow it's not too hard to keep going. Many of my days go like this: (1) get into work (2) check email, read the web, etc. (3) decide that I might as well have lunch before getting to work (4) get back from lunch (5) check email, read the web, etc. (6) finally decide that I've got to get started (7) check email, read the web, etc. (8) decide again that I really have to get started (9) launch the damn editor and (10) write code nonstop until I don't realize that it's already 7:30 pm.

Somewhere between step 8 and step 9 there seems to be a bug, because I can't always make it across that chasm. For me, just getting started is the only hard thing. An object at rest tends to remain at rest. There's something incredible heavy in my brain that is extremely hard to get up to speed, but once it's rolling at full speed, it takes no effort to keep it going. Like a bicycle decked out for a cross-country, self-supported bike trip -- when you first start riding a bike with all that gear, it's hard to believe how much work it takes to get rolling, but once you are rolling, it feels just as easy as riding a bike without any gear.

Maybe this is the key to productivity: just getting started. Maybe when pair programming works it works because when you schedule a pair programming session with your buddy, you force each other to get started.


When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can't fire at you. (That's what the soldiers mean when they shout "cover me." It means, "fire at our enemy so he has to duck and can't fire at me while I run across this street, here." It works.)  The motion allows you to conquer territory and get closer to your enemy, where your shots are much more likely to hit their target. If you're not moving, the enemy gets to decide what happens, which is not a good thing. If you're not firing, the enemy will fire at you, pinning you down.

I remembered this for a long time. I noticed how almost every kind of military strategy, from air force dogfights to large scale naval maneuvers, is based on the idea of Fire and Motion. It took me another fifteen years to realize that the principle of Fire and Motion is how you get things done in life. You have to move forward a little bit, every day. It doesn't matter if your code is lame and buggy and nobody wants it. If you are moving forward, writing code and fixing bugs constantly, time is on your side. Watch out when your competition fires at you. Do they just want to force you to keep busy reacting to their volleys, so you can't move forward?

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don't have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby. Are you going to support Hailstorm? SOAP? RDF? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond? The sales teams of the big companies understand cover fire. They go into their customers and say, "OK, you don't have to buy from us. Buy from the best vendor. But make sure that you get a product that supports (XML / SOAP / CDE / J2EE) because otherwise you'll be Locked In The Trunk." Then when the little companies try to sell into that account, all they hear is obedient CTOs parrotting "Do you have J2EE?" And they have to waste all their time building in J2EE even if it doesn't really make any sales, and gives them no opportunity to distinguish themselves. It's a checkbox feature -- you do it because you need the checkbox saying you have it, but nobody will use it or needs it. And it's cover fire.

Fire and Motion, for small companies like mine, means two things. You have to have time on your side, and you have to move forward every day. Sooner or later you will win. All I managed to do yesterday is improve the color scheme in FogBUGZ just a little bit. That's OK. It's getting better all the time. Every day our software is better and better and we have more and more customers and that's all that matters. Until we're a company the size of Oracle, we don't have to think about grand strategies. We just have to come in every morning and somehow, launch the editor.



行进中开火[转]

Author: Joel Spolsky    
译： Siyan Li 李思延
编辑： Paul May 梅普華

　　时不时，总有一阵儿，我什么事也干不了。

　 　我也去办公厅，东瞄瞄，西看看，每十秒钟查一次电子邮件，网上逛一圈。也许干点儿象付运通卡账单之类不需要大脑的事。不过要回去哗啦哗啦写程序，可没门 儿。这种不出活的状态，一般通常会持续一两天。在我的软件开发生涯中也有过几个星期干不了活的时候。就像他们说的，我不在状态，我进入不了情况，我找不到 组织。

　　人人都有情绪波动，有的人温和一些，有的响动大点儿，也有的可以整个乱套。但不管怎么着，那段不出活期似乎总是跟忧郁有点儿关系。

　　我不由得联想到那些专家说，人们基本上控制不了自己吃什么。任何节食计划都长不了。大家总是悠回各自的正常体重。也许作为一个软件工程师，我也不能控制什么时候最能出活。我唯一希望的就是发呆那段能被哗哗干活那段扯平，最终还能混碗饭吃。

　 　自从我干上软件开发这一行起，我平均每天只有两三个的高效时间。这真让我头大。我在微软实习的时候，另外一个实习生告诉我，他每天12点上班，5点下 班。5个钟头还包括午餐时间，但他的同事还对他特别满意。因为他干的活比一般人都多。其实我也一样。我每天只有两三个小时的高效时间。看着别人那么卖力的 干，还有点不好意思。不过呢，我总是组里出活最多的。由此可见，“人件理论”和极限编程都坚持不加班，每周只干40小时，还是有点道理的。他们都清楚这么 做不会降低一个小组的生产能力。

　　每天只能干两小时还没让我太担心，真让我担心的是完全干不了活的那些天。

　 　我老想这是怎么回事儿。我努力回忆我出活最多的时候。估计是微软把我搬到一间漂亮的新办公室的时候。舒适豪华的办公室，窗外风景如画，窗对面樱桃花开满 了石头堆砌的庭院。所有的一切都那么恰到好处。我马不停蹄地干好好几个月，一口气把Excel Basic的详细设计搞定。用象纪念碑那么高的一叠纸，详细描素了一个超大型目标模型和编程环境，工作之细致，令人难以置信。我自始至终就没停过手。去波 士顿参加MacWorld I的时候，我都带着一台手提电脑，坐在哈佛商学院的大阳台上把Windows类别的所有文件都写完了。

　 　按步就班并不难。通常我一天是这样度过的：1，去上班。2，查电子邮件和上网等等。 3，考虑是否应该吃完中饭在开始干活。4，吃完中饭回来。5，查电子邮件逛网。6，终于决定应该开始工作了。7，查电子邮件逛网，东瞄瞄，西看看。8，再 次决定确实应该开始开始干活了。9，打开该死的编辑器。10，一直会些程序学到晚上7：30，写到忘记时间。

　　在以上第8步和第9步之间似乎有点缺陷，因为我不是每次都能顺利地执行下去。

　 　对我来说，启动是唯一的难题。静止物体在不受外力作用的情况下会保持静止。大脑里有些物质的质量大得不可思议，让它加速太难了。但是只要速度上去了，在 全速行使的情况下，倒不用使什么劲就能继续走下去。就象骑着自行车去作一次自费横穿美国的旅行，一开始，你根本想象不出要花那么多时间让车轮动起来，可是 一旦动起来了，让它们继续转就不是一件很难的事了。

　　也许高效率的关键就：启动起来。配对编程法之所以成功，说不定就靠两个人在一起，互相强迫对方启动起来。

　 　我在以色烈当伞兵时，一次，有个将军来给我们讲实战战术。他告诉我们，步兵战术其实只有一种：行进中开火。你一边开火一边朝着敌人冲过去，火力让敌人抬 不起头来，不能朝你开火 (当一个军人喊：“掩护我”的时候，他的意思就是“在我冲过街时候，你朝敌人猛烈开火，迫使他猫起来，没法朝我开火)。前进了，你就可以占领阵地，接近敌 人，这样你的胜算要大的多。你要是不往前冲，敌人就有时间来搞清楚形势，这可不妙。你要是不开火，敌人就要朝你开火，撂倒你。

　 　我很长一段时间都在想着这个教导。我想通了不论是战斗机空中格斗还是大规模舰队攻击，大部份军事战略战术都是以行进中开火作为基础的。我又化了十五年时 间才想通了行进中开火也是一个人在现实生活中成功的基本原则。你每天都得往前进点儿，不用想你写的程序怎么差劲，怎么卖不出去，只要你不停地写，不停地 改，滴水也能穿石。同时， 要注意你的竞争对手朝你开火。他们是不是想让你全心全意应付他们的扫射，好让你往前走不了呢？

　 　想想这些年来，微软开发出来的资料存取方法，从OBDC，RDO，DAO，ADO，OLEDB直到现在的 ADO，.NET，不停翻新，技术上有必要吗？还是因为那个设计组实在蹩脚，每过他妈一年就得重新发明一遍资料存取技术？(实际上可能真是)。它最终的效 果其实是一道掩护火力，让竞争者别无选择，只能把本来该用来开发新功能的宝贵时间都用来移植和升级了。仔细看看软件行业，干得好的公司对那些对大公司都依 赖最少，不用把所有精力都用来为赶潮流而把程序重写一遍，还得修改那些只有在Windows XP上才会出现的缺陷。那些花太多时间去猜测微软未来发展方向的公司，日子都好过不了。有些人见了.NET就发怵，忍不住要按.NET来完全重建自己的体 系结构，以为自己别无选择。哥门儿，看清楚了，微软是在朝你开火呢，而且这只是掩护火力。这游戏就是这么玩儿的。这样一来，他们就可以大步朝前走，而你却 不能。你要支持Hailstorm吗？SOAP呢？还有RDF？是因为你的顾客需要，所以你支持它们？还是因为有人朝你开火而你觉得应该还击？大公司的营 销部都懂火力掩护。他们到客人那儿就说，“你们不一定非买我们的。谁的产品最好您就应该买谁的。不过，我们想提醒您，在下单之前最好先确认他们支持 (XML/ SOAP/CDE/J2EE)。否则你们就会被他们的技术套牢。”。等到小公司去向这个客户推销的时候，那个听话的CTO就会问他们：“你们有J2EE 吗？”。他们回去就只好不管卖不卖得掉，都埋头打造他们的J2EE。他们也就再没有机会来展示自己的特色了。其实，这只不过是个打勾功能。因为有个打勾拦 在那儿空着，你就必须有这个功能。其实谁都不需要它。这就是火力掩护。

　　对于我这样的小 公司来说，行进中开火意味着两件事。别跟时间过不去，同时你还得每天都进步。天不负苦心人，你终有出头的一天。我昨天花了一天时间只不过让FogBUGZ 的颜色稍微好看点。这不要紧，只要不停步。最重要的是，我们的软件越来越好，客人越来越多。在我们达到Oracle 的规模之前，我们并不需要通盘战略。我们只需要每天早晨到办公室来，别多想，打开编程器。