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