Fire and Motion

By Joel Spolsky
Sunday, January 06,200 2

Sometimes I just can't get anything done.

Sure, I come into the office, putter around und, 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'tControl 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
Work from 12 to 5 every day. Five hours, minus lunch, and his teamLovedHe 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
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 doAnything.

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 login ented the window class sitting on a pleasant terrace at Harvard.

Once you get into flow it's not too hard to keep going. Since 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 IReallyHave to get started
(9) Launch the damn editor and
(10) write code nonstop until I don't realize that it's already PM.

Somewhere between Step 8 and Step 9 there seems to be a bug, because I can't always make it into SS that chasm.
Me, just getting started isOnlyHard 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 paratrow.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 guest SS 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 semantic 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. net because they think they have. 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, buby. Are you going to support hailstorm? Soap? RDF? Are
You supporting it because your MERs 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 MERs 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 operate 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 we have more and more MERs 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.

 

Translation: Siyan Li lisiyan
Edit: Paul may mappers

From time to time, I can't do anything for a while.

I also go to the office, East for a purpose, and West for a look. I check my email every 10 seconds and go around the Internet. Maybe you don't need to worry about anything like paying a card bill. But you have to go back and write programs. This inactive state usually lasts for a day or two. In my software development career, I also had a few weeks of failure. As they said, I am not in the status, I cannot enter the situation, and I cannot find the organization.
Everyone is subject to mood fluctuations. Some are gentle, some are louder, and some can be messy. But no matter what it is, that period of time does not always seem to have something to do with melancholy.
I can't help but think of experts who say that people basically cannot control what they eat. No diet program can grow. Everyone is always wandering back to their normal weight. Maybe, as a software engineer, I cannot decide when to work. The only thing I hope is that I can get flushed when I am in a daze, and finally have a bowl of rice. Since I started software development, I have only two or three efficient times per day. This really makes my head big. During my internship at Microsoft, another intern told me that he went to work at every day and got off work. Five hours also included lunch time, but his colleagues were very satisfied with him. Because he does more work than the average person. The same is true for me. I only have two or three hours of efficient time every day. I'm sorry to watch others do so hard. However, I always have the most active members in the group. It can be seen that both the theory of "human ware" and extreme programming insist on not working overtime and working only 40 hours a week, which makes sense. They all know that this will not reduce the productivity of a group.
I can only do two hours a day without worrying too much. What worries me is that I cannot do anything for those days.
I always wondered what was going on. I tried to recall when I was the most active. It is estimated that Microsoft moved me to a beautiful new office. Comfortable and luxurious office, picturesque outside the window, the cherry blossom across the window is filled with stone stacked courtyard. Everything is just right. I have been working for several months without a stop and completed the detailed design of Excel basic in one breath. With a stack of paper as high as a monument, detailed descriptions of a super large Target Model and programming environment are incredibly meticulous. I never stopped. When I went to Macworld I in Boston, I took a laptop and sat down on the big balcony of Harvard Business School to finish writing all Windows files.
It is not difficult to use a pay-as-you-go method. I usually spend the following day:
1. Go to work.
2. check emails and access the internet.
3. Check whether you should finish your lunch and start working.
4. Come back after lunch.
5. Check your email to visit the internet.
6. Finally, I decided to start my work.
7. Check the email and visit the Internet. Check the east and west.
8. I decided to start working again.
9. Open the damn editor.
10. I will keep learning some programs at and write them to forget the time.
It seems a bit flawed between the above steps 8th and 9th, because I did not perform it smoothly every time.
For me, starting is the only problem. Static objects remain static without external force. The quality of some things in the brain is incredible, making it hard to accelerate. However, as long as the speed goes up, you don't have to make any effort to continue when the speed goes up. It's like riding a bicycle for a trip across the United States at your own expense. At first, you couldn't imagine that it would take so much time to get the wheel up, but once it got up, it is not very difficult to keep them going.
Maybe the key to efficiency is to start up. The successful pairing programming method may rely on two people together to force each other to start up.
When I was serving as an umbrella soldier in sellie, a general came to tell us practical tactics. He told us that there is actually only one type of infantry tactics: open fire. As you open fire and rush toward the enemy, the fire forces the enemy to lift its head and cannot open fire at you (when a soldier shouted "Cover me, he meant, "When I rushed across the street, you fired at the enemy and forced him to get up and couldn't open fire at me ). As you move forward, you can seize the position and approach the enemy. In this way, your odds are much greater. If you don't rush forward, the enemy will have time to figure out the situation. If you don't open fire, the enemy will open fire at you and kill you.
I have been thinking about this teaching for a long time. I figured out that most military strategy and tactics are based on ongoing fire, whether it's air combat or large-scale fleet attacks. It took me another 15 years to figure out the basic principle of a person's success in real life. Every day, you have to move forward. You don't have to think about how bad the program is. How can you not sell it? As long as you keep writing, changing, and dripping water, you can also wear stones. At the same time, pay attention to your competitors opening fire on you. Do they want you to handle their spams with all your heart, so that you can't move forward?
Think about the data access methods developed by Microsoft over the years, from obdc, rdo, Dao, ADO, and oledb to the current ADO and. Net, which are constantly being refurbished. Is it technically necessary? Or is it because the design group is really poor, and every year it will have to re-invent the data access technology? (Actually ). Its final effect is actually a protection of firepower, leaving competitors with no choice but to use the precious time that should have been used to develop new functions for transplantation and upgrade. Take a closer look at the software industry. Companies that do a good job have the least reliance on big companies, so they don't have to spend all their energy on rewriting the program to catch up with the trend, you have to modify the defects that only occur on Windows XP. Those companies that spend too much time speculating on Microsoft's future direction will not be able to survive. Some people have seen. net, and they can't help but follow. Net to completely reconstruct their own architecture and think they have no choice. As you can see, Microsoft is opening fire on you, and this is just a cover for firepower. That's how this game works. In this way, they can stride forward, but you cannot. You want to support hailstorm
? What about soap? And RDF? Because your customers need them, do you support them? Or is it because someone fires at you and you think you should fight back? The marketing department of a large company understands the fire protection. They said, "You may not have bought us. You should buy the best product. However, we would like to remind you that it is best to confirm their support before placing an order (XML/soap/CDE/J2EE ). Otherwise, you will be stuck by their technology .". When a small company sells to this customer, the obedient CTO will ask them: "Do you have J2EE ?". When they went back, they had to build their J2EE, no matter whether they were sold or not. They have no chance to show their own characteristics. In fact, this is just a check function. Because there is an empty check box, you must have this function. In fact, no one needs it. This is the fire protection.
For a small company like me, opening fire on the road means two things. Don't go through time, and you have to make improvements every day. You have a hard time. I spent one day yesterday, but it only showed a little better color for fogbugz. This doesn't matter, as long as you keep walking. The most important thing is that our software is getting better and better, and there are more and more guests. Before we reach Oracle, we do not need a comprehensive strategy. We only need to come to the office every morning. Don't think about it. Open the programmer.