Joel on Software
Fire And Motion
by Joel Spolsky Sunday, January 06, 2002
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 peoplecan'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.
最让我抓狂的是：我从第一份工作就意识到，作为一个程序员，每天真正能写出代码的时间不超过两到三小时。我在微软实习的时候，另一个早来的实习生告诉我他每天实际的工作时间是从12点到5点。 5个小时还要减去午饭时间，他所在的团队依然器重他，因为他的效率高于平均。我也是这样认为的，当我看到人们努力工作时我也会有些内疚，但我仍是团队中最有效率的成员之一，尽管我每天真正工作的时间只有两三小时。这也许正是人件和极限编程坚持削减加班并严格执行一周40小时工作制的初衷，他们知道这样并不会削减团队的产能。
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.
我思考了很久，并试着想起我职业生涯中最有效率的日子。那大概是在微软刚搬办公室之后，新办公室风景如画，透过大大的窗户可以看到漂亮的石头庭院，院子里栽满了的樱桃树，一切都是如此契合。几个月内，我马不停蹄的写出了ExcelBasic的详细规格说明书——超大的一份文档其中事无巨细的描述了庞大的对象模型和开发环境。那期间我真没停下来过。当我必须去波士顿参加MacWorld会议时，我都随身携带了个笔记本电脑，坐在哈佛商学院漂亮的阳台上，继续写我的窗口类文档。
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.
一旦进入了状态，要持续高效的工作并不难，大部分的时候，我的工作日是这样的：1 上班 2 查邮件、看网页 3决定也许可以吃完午饭再干活儿 4吃完午饭 5查邮件、看网页6终于决定我该干点儿活儿了 7继续查邮件，看网页 8 再次决定我真的必须开始了 9打开该死的编辑器 然后 10不停的写代码直到突然发现已经到晚上7点半了。
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.
由第8步迈向第9步似乎有些困难， 因为我不是每次都能越过那道槛。于我而言，开始是最难的。静止的物体趋向于保持静止。我头脑里似乎有些重得出奇的东西让我的大脑很难开始运作，一旦它开始高速运作，要保持这种状态就不难了。就像骑自行车全国自助游 – 当你第一次骑那种全齿轮组自行车，很难想像要费多大劲才能使它们开始转动，但其实只要运转起来，骑起来就像没有齿轮组的自行车一样轻松。
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?
我一直记得这次演讲。我注意到几乎所有的军事策略，从空军的空战，到大规模的海军战役，都是由移动并开火发展来的。 我又花了另外的15年才明白，移动并开火也是你生活中成功的原则。你每天都得向前前进一点点。也许你的代码写得很烂又有很多错误而且没有人想要，这并不重要。如果你时常都在前进，持续写代码并修正错误，时间就站在你这边。而当你的竞争对手朝你开火时，你也要注意，他们是否为了让你忙于应对他们的进攻，而使你无法前进。
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.
想想微软历史上推出的数据访问策略产品。ODBC,RDO,DAO,ADO,OLDEDB 然后是现在的ADO.NET – 全部是新的！这些新的技术都是必要的么？ 这是因为不称职的产品架构组导致每年都该死的要重做数据访问么？（实际上这非常有可能） 但本质上来说都是“掩护”。 竞争迫使它们除了把时间花在移植和升级上之外别无选择。仔细观察软件行业你就会发现，那些做得好的公司都是对大公司依赖小的公司，他们不需要把所有的生产周期花费在升级，修正那些只会在WindowsXP上产生的错误。那些走的跌跌绊绊的软件公司都花了太多时间去思考微软的未来方向。他们会担心.NET，然后决定为.NET重新架构系统因为他们觉得必须这么做。微软在朝你“开火”，这只是一种掩护，然后微软能够前进而你不能，这就是游戏规则。朋友，你要支持Hailstorm？SOAP?RDF吗？你支持它们是因为你的客户需要他们呢？还是因为有人在朝你“开火”然后你觉得你必须有所反应？大公司的销售团队都懂得“掩护”。他们会对客户讲，“好，你不要从我们这儿买，从最好的供应商那儿买，但你要确定你买到的产品支持(XML/SOAP/CDE/J2EE)否则你将受到限制”。然后当小公司尝试去销售给那个客户的时候，他们能听到的就是CTO在鹦鹉学舌 “你们有用J2EE么？”即使这和销售没有任何关系，小公司也要花费所有的时间去构建支持J2EE，同时这也让他们的产品失去辨识度。就像个复选框特性 – 你实现这个特性只是因为你需要复选框来表示你有这个特性，但不会有人需要它甚至用它。 因为那只是“掩护”而已。
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.
移动并开火，对于像我们这样的小公司而言，意味着两件事情。你必须让时间呆在你这边，然后你必须保持每天前进。总有一天你会成功的。我昨天做的事情就是改进一点FogBUGZ里的颜色方案而已。那就够了。它一直在变好。 每天我们的软件都越来越好，然后我们就有越来越多的客户，这才是最重要的。在我们的公司变得跟甲骨文一般规模的之前，我们都不需要考虑基础战略。我们只需要每天早晨上班然后想办法打开编辑器。