Fire And Motion：聚焦前进，避免当炮灰

Fire And Motion

原文：https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

2002年01月06日，JOEL SPOLSKY，Trello联合创始人，如果大神你不知道Trello是什么，那么你肯定知道Stack Overflow，嗯，我是StackOverflow的CEO。

有时候，我就是啥事也没有干出来，啥事也没有干成。

和你一样，我每天可是准时按点到公司，到处晃悠晃悠，然后回到我的座位上，每隔几分钟看看邮箱，然后看看微信朋友圈，读读今日头条，有时候甚至会花时间付下淘宝天猫的账单。可惜我就是没法进入状态好好写代码。

一般持续有两三天，我都处在这种毫无生产力的状态。在我码农的生涯中，有几次竟然好几周都是这样，以至于我啥也没干成。就像大神说的，我没法进入那种写代码的忘我的高效的飘飘欲仙的Flow境界，实际上我迷迷糊糊浑浑噩噩一团糟。

每个人都有心情不好的时候，就像大姨妈一样每个月都要来几天。有些人症状比较轻微，而有些人简直不忍直视。而效率低下貌似确实和糟糕的情绪有关。

这让我想起了类似的事，由于人几乎无法控制饮食，所以节食减肥总是要反弹，减肥的胖纸始终会变成更胖的胖纸。而作为一个码农，虽然不能随意的进入Flow境界，但我至少得让自己能写出代码来，不然长期效率低下，饭碗都要没了。

我第一份工作时，意识到每天我只有2到3小时高效的写代码，这让我很鄙视我自己。后来我在Microsoft实习时，有个人说他只在下午12点到17点才上班，他每天只上班5小时（还要刨掉吃午饭时间），但是他的Team都非常喜欢他，因为他的产出非常高，比平均产出要高一大截。比起来我感觉我自己就是个残废，虽然我和其他人看起来每天8小时努力工作，但是实际上我只有2到3小时是真正在高效的工作的，更可笑的是，我还是我们Team产出最高的，可见别人一天忙到晚真正有多少时间有效的工作了。这是为何《人件(Peopleware)》和《敏捷编程(XP)》中坚持鄙视加班行为，每周只要工作40小时就足够了，绝对不会降低产出的。

而且我担心的不是每天只有2小时有效工作时间，我担心的是我一整天我啥事也干不出来的情况。

关于工作效率，我思索了很久。我回想了我啥时候最有效率，可能是在微软那段时间，我们搬到了一个非常漂亮的新办公区，院子里樱桃树开满了花，诸事完美。在接下来的几个月里，我根本就停不下来，我马不停蹄的编写ExcelBasic的规范，非常复杂的工作需要描述对象模型和编程环境，那文档可是撂起来跟山一样高啊。

一旦你进入Flow境界，你就爽到停不下来了。可惜我一天大部分是这样的：

1. 开始上班
2. 收发邮件，刷微信朋友圈，看今日头条
3. 不知不觉的，已经到了吃午饭的时间了，先吃午饭
4. 吃午餐回来
5. 继续刷朋友圈，看今日头套
6. 下定决心要开始干正事了
7. 还是忍不住刷了下朋友圈，看了条新闻
8. 终于下定决心要开始干正事了
9. 打开那个鬼IDE，噼里啪啦的敲代码直到晚上，一抬头就7点半了

我第8和9步之间貌似有BUG存在，因为我总是无法果断的从第8步直接到第9步，总是7-8-7步之间徘徊。实际上，真正关键的，以及真正的困难不过就是直接开始干活，对的，啥事也不要想，先直接进入第9步。正如牛顿哥所说，静止的事物总是想保持静止，好像我脑袋里有啥特别重的东西，阻碍我直接进入第9步运动起来。不过如果跑起来后，好像就不用费什么力气了，就像自行车一样，骑起来之后就不会像启动时那么费劲。

我想保持高效率工作的关键就是：撸起袖子开始干，从第1步直接跳到第9步。在敏捷编程中有个方法叫做“结对编程”，结对编程之所以有效，可能是因为你让你的搭档直接开干的缘故。

我以前在以色列当伞兵时，将军和我们说，陆战中只有一个策略：Fire and Motion，向敌人冲锋的同时一定要向敌人开火，这样敌人就没法抬头攻击你。这也是士兵喊“cover me”的意思，就是向敌人开火。只有保持前进，才能离敌人更近，更容易干掉敌人；如果你不开火，你的敌人就会开火，就会被敌人牵制，这可不是什么好事，容易变成炮灰。

我把这个策略铭记于心，而几乎所有的军事策略中，不管是空中缠斗，还是海军战斗，都是建立在Fire and Motion的基础上的。十五年的工作和创业经验，让我意识到，要干成点啥事，提高成事的概率，也必须遵守Fire and Motion的准则。你必须每天前进一点，可能没有人鸟你，也不管你的代码多烂都没有关系。只要你每天前进一点，不断的写代码，解决bug，那成事是迟早的事情。要注意你的竞争对手可能会给你挖坑，他会向你开火的，有可能他只是希望你忙于应付他的各种招式，而让你疲于奔命而忘记前进了，你就变成了炮灰。

让我们看看Microsoft这些年的数据访问技术，包括ODBC、RDO、DAO、ADO、OLEDB，现在是ADO.NET，一直都有新技术搞出来装逼，这些技术是有必要的吗？难道他们的驾狗师就那么弱智，以至于每年都要推翻搞个新的技术出来？（有可能是真的，哈哈）但我觉得这不过就是掩护的火力，让竞争对手疲于奔命变成炮灰。活的滋润的公司从来不跟进和依赖大公司的技术路线；而整天琢磨Microsoft下一代技术的公司总是活得很惨，这些公司把自己的产品用.NET重写了，因为他害怕跟不上Microsoft的步伐。而这些新技术不过是Microsoft的掩护火力，这样你就变成了炮灰，而Microsoft却在继续前进。你准备要支持Hailstorm、SOAP、RDF吗？是因为你的客户需要用到，还是你的竞争对手用这个技术打你，希望你变成它的炮灰？大公司的销售非常懂得这一点，他们跑到客户那里然后说，“嗯，你丫可以不从我们这里买，不过你得找到一个供应商支持XML、SOAP、CDE、J2EE，不然这些技术被淘汰就满足不了业务要求了“；然后客户跑到小公司那里，问”你们产品支持J2EE吗？“，小公司只好浪费花时间支持J2EE，而放弃继续前行，实际上客户从来都不会用J2EE。

如果一个功能，只是因为别人有了你就需要有，但是实际上它并没有什么卵用，那么它就是竞争对手的掩护火力，你就变成了它的炮灰，应该要小心不要浪费时间在这个上面，而要花时间在前进上面。

对于像我这种小公司，Fire and Motion意味着两件事：

1. 必须要有足够的时间，用在高效工作。
2. 时间必须要花在前进的工作中，而不是疲于奔命当竞争对手的炮灰。

如果做到这两点，假以时日，成事就如囊中取物瓮中捉鳖。以前我不断的改进FogBUGZ的配色，每天改进一点点，它不断的在变好；我们的软件每天都在变好，我们有越来越多的客户，这才是最重要的事情。除非你是Oracle这种大公司，才需要想大的战略；我们只需要每天早上上班，直接跳到第9步，撸起袖子开始干~

原文：https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

JANUARY 6, 2002 by JOEL SPOLSKY

Fire And Motion

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.bike trip 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.

ABOUT THE AUTHOR.

I’m Joel Spolsky, co-founder of Trello and Fog Creek Software, and CEO of Stack Overflow. More about me.