Turn to The Last Word, where software professionals who care about quality give you their own opinions on hot topics. Find out what Peter Clark really thinks about overtime and why Lance Armstrong may hold the secret to success.
Software projects are rather like marathons. To finish one, you have to go a long way in a limited time. There are milestone marks along the way to let you know whether you are on pace or not. At some point, you're likely to reach a milestone mark a bit behind schedule, prompting an overpowering urge to begin sprinting—to just go as hard as you can to try to catch up, or even just to avoid falling farther behind. However, this can easily make your problem worse, rather than better.
Software projects can last for months, or even years. If you yield to the temptation to try to sprint to keep up, eventually you will end up on the side of the road. Luckily, there are things that you can do to pace yourself so that you still have something left (like your sanity) at the end of the race.
Practice Smart Sprinting
During the Tour de France last summer, I watched Lance Armstrong sprint uphill. I noticed that he would get up out of the saddle and ride hard for a minute, resume his more normal pace sitting in the saddle, then get up and ride hard again. Lance allowed his body to recover for a certain length of time after each period of extraordinary exertion. He could have sprinted out of the saddle for five minutes straight, but his legs would have been toast, and he would have lost ground to the pack.
Applying the Lance Armstrong sprinting method to software projects, I recommend a week or two of no more than twenty hours overtime followed by a refractory period of one or two weeks before putting in any additional overtime. This gives you the opportunity to recover from the strain and catch up on things outside of work that you were ignoring. In my experience, working extended periods of overtime will ultimately reduce productivity to less than a forty-hour week.
I also recommend being mindful of pace during each workday. Make time for change-of-pace tasks—reading email, handling paperwork, and returning phone calls. This will give you a breather from your exertion and give you a chance to recover and return to your project refreshed. Also, scheduling these interruptions is more effective than handling them ad hoc. It gives you more time "in the flow," where you are at your peak productivity.
Don't Forget Sleep
There used to be a bicycle race from Los Angeles to Washington, DC. The first few years it was run, the cyclists would ride for thirty-six hours straight, crash for a couple of hours, and then get back on their bikes and do it again. Then came a biker who rode at a high rate for a shorter period of time, and who got a normal night's sleep. He won the race by a wide margin. So it is with knowledge work on software projects—rest counts.
When you start working harder and longer, sleep is one of the first things to suffer. You try to add hours to the day by taking them away from your sleep time. Missing sleep quickly affects your performance to the point where you are less productive than if you were working less and sleeping more. It affects your judgment so that you are less likely to be able to tell if you are having problems. You drag yourself through your days accomplishing little, except for showing up for unreasonably long hours.
Short periods of intense overtime are okay, but marathon sessions will catch up with you. Perhaps some people are stress monkeys and can go for days
|Pace Wins the Race||69.31 KB|