Home for the Holidays

As the holiday season approaches, projects tend to slow down. How do you join the human race?

Q. Where people live in the same room?—A. In the majority of cases I found that they lived, work, and sleep in the same room.

Q. Do they make any distinction between their workroom and their sleeping room?—A. No, sir; they work in all.
—Mrs. T.J. Morgan, testimony to the Congressional Committee on Manufactures, 1893

At the end of the nineteenth century, the "sweating system" was a problem of great concern. Under this system immigrant workers essentially were worked until they dropped, at the lowest of piecework rates. Various pieces of labor legislation came about as a result, and as a society we decided that this sort of work was A Bad Thing.

However, it seems to be the fashion in some circles of computer management to try to sneak the sweating system back in, albeit with higher wages. Most software managers don't write explicitly about the hours they expect from their employees, but a few do. Here's part of an article by Philip Greenspun from Ars Digita:

If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project. If you see one of your average programmers walking out the door at 6:00 pm, recognize that this person is not developing into a good programmer. An average programmer's productivity will never be significant in a group of good programmers. If you care about profits, you must either come up with a new training program for the person or figure out the best way to terminate his or her employment with your organization.

Elsewhere in the article, Greenspun makes it clear that he expects developers to work 55- to 70-hour weeks, and counsels managers to find ways to keep their employees in the office that long. Many of us happily comply, because (face it), we like fighting with recalcitrant software. There's a certain chest-thumping satisfaction to finally wrestling that bug to the ground and pummeling it, and then remarking over a breakfast of cold pizza and Mountain Dew that you haven't been home in three days.

Developer Central in Your Mailbox
Want to read more of Mike's work? Sign up for the monthly Developer Central e-newsletter, including product reviews, links to web content, and more, at http://lists.101com.com/NLS/

That's fine for some people, but just in case you haven't looked out the window lately (or your boss doesn't believe in giving you a window), there's snow on the ground. The holiday season are coming. Isn't it time to think about trying to find some balance between your life-sucking career and your home and family?

Looking Out the Window
I'm a fine one to talk: I work at home and on the average week I spend more like 70 hours in front of my computers than 40. But even so, I've slowed down a bit; all-nighters are becoming increasingly rare for me. (First one to mention increasing age gets whacked with my cane.) So, while I sympathize with those of you still putting in dot-com hours in a post-crash world, let me offer a little bit of advice.

My first piece of advice is quite simple: Decide what's really important to you in life. It's entirely possible that a fulfilling career and good paychecks are all you care about, in which case you can pretty much skip the rest of this column. But how about a family? The chance to play a team sport in your spare time? Hiking in the Adirondacks? Cooking gourmet meals? If you want to do any of those things, you'll need to find time for them. There are only 168 hours in a week, and they're not manufacturing any more. If you knock off 70 of those for work, get eight hours of sleep a night and add commuting time and basic personal hygiene and the occasional meal that doesn't come from a vending machine, what's left is not enough hours to pursue non-work activities. Make a realistic estimate of how many hours you'd like to spend out of the office, and you'll know how many hours you're prepared to spend in the office.

You'll notice that I said "realistic." Software developers are, alas, not known for their ability to make realistic estimates. This applies to personal life just as much as to software projects. If your team is prone to estimates like "well, we can compress final test into three days, because by then we'll have been using the code for a month," you're likely to also believe that you can learn French in three days if only you can find the right set of tapes to listen to during your commute. Try not to believe yourself, OK? The key thing to remember is that none of us works at our peak all of the time. Just because you once wrote ten lines of error-free code in a minute is no reason to believe that you can turn out 4,200 error-free lines in a week.

Dealing With The Boss
So, you've decided that you need to get your work week down to something sane, like 40 or 50 hours a week. Now what? The biggest obstacle to this plan in all too many organizations is the line manager. Your manager, after all, is the one responsible for bringing in project X by date Y. He's the one who has to deploy resources to get that done. And if he's used to thinking of you as a 70-hour resource, chopping away 30 percent or more of your schedule may be more than he can bear.

The key to pulling back in this situation is to convince your boss that you're not really pulling back at all—that by working smarter, you can deliver the same results in 50 hours that he's expecting in 70. If your manager is honest, he knows that none of his employees actually have 70 productive hours in the office in a week. Faced with that sort of day, we all end up paying bills, taking long lunches, or chatting with our significant others via instant messenger software. Point out that by working sensible hours, you can focus on actual work. Plus if you actually get some sleep, you can come into the office refreshed and ready to work, instead of spending your first hour at your desk reading SlashDot.com and consuming mass quantities of caffeinated beverages.

Good managers will recognize that performance and delivery is more important than raw hours spent with butt applied to chair. Ideally, you can work together to define the milestones that you need to meet and when you need to meet them. Then it's up to you to schedule your time properly to get your work done. If you've gone through the exercise of deciding what's important, you should have plenty of incentive to work more efficiently.

If your boss responds with "Great! If you can do that, I can put you down for 25% more work in your 70 hours!", then it really is time to be hunting another job.

Another thing to keep in mind is that most software projects don't require the same level of commitment throughout. Typically, there's a lot of up-front planning that requires burning the midnight oil while the architecture is settled, a mad rush to meet deadlines at the end, and a long stretch of just plain coding in the middle. If you're conscientious about contributing during the pressure times, most managers won't mind if you back off a little during the routine times—as long as you keep delivering.

Working Smarter
Finally, let me return to a theme that I've touched upon many times before: Work smarter, not harder. I recently realized that I was spending an average of half an hour a day rebooting my main development box—by the time I shut down all my applications, reboot, and fire everything up again, that's how long it takes. This was happening because I simply didn't have enough RAM for everything that I wanted to run, but my motherboard was maxed out. The solution, of course, was to upgrade the motherboard and RAM together. Yes, it cost me a chunk of money. Yes, it cost me a couple of days to backup, change hardware, and reinstall. But a half hour a day is 15 eight-hour days over the course of a year, even if you take weekends off. That's a lot of time to be wasting when there's an obvious solution.

As a developer, you're supposed to be a smart cookie. Take some of that smarts and apply it to your own working day. Are you spending 20 minutes a day babysitting a manual build process? Does your source code control system munch files, losing weeks of work? Would a debugging terminal on the COM port make short work of tough bugs? These are all problems that can be solved with the proper application of existing tools. Yes, tools cost money. But in almost every case, if you do your research and find the right tool, they'll pay for themselves in increased productivity.

And increased productivity pays for itself in time off, which you can use to eat that big turkey dinner with the family. Bon appetit!

Or maybe you're working long hours to get away from your family? Are you just dedicated, not crazy? Write and let me know. I'll use the most interesting comments in this column and a future issue of Developer Central.

About the Author

Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.


comments powered by Disqus

Subscribe on YouTube