Overtime makes programmers less productive.
You have to be in the
right mood, called "flow" by many, to be a good programmer. Different
hackers can get into and out of this state more or less easily, and it is a
large part of what determines their quality. When this blog was just a
simple paper journal and not a multi-billion dollar
media empire *, I spilled huge bottles of ink on wondering what the
magic formula for instantly dropping into flow was. I've talked about it a
lot with my friends in the years since then.
As the Tao and most physics teaches us, though, any powerful force has an
equally powerful opposite. So it is with Flow, and I have experienced it:
the Anti-Flow.
There's a lot of hacker mythology about working late into the night, eyes
glazed over, blissfully hacking away on some deep problem, unaware of the
outside world. It is generally acknowledged that this is a state of Being At
One With The Machine. I believe that this is a false enlightenment. After
this last round of crunch time, I have realized its true nature. After a
certain number of hours of working, you think you're in flow. It seems as
though everything is going well. What's really happening is that your mind
is playing tricks on you: you're tired, you're making mistakes, but you're
just not seeing them.
I think this is why the first programming
methodology to get really bothered about programmer-written tests was
also the first one to start complaining loudly that we should stick to a
forty hour week. When
you're just writing and writing and writing code, it doesn't occur to you
that you're producing garbage, or if not garbage, at least substantially
lower-quality code than usual. You hit your testing phase later, and you fix
your bugs, and you shrug and think "that's software for you". It seems like
you're productive on both ends, since you're producing lots of code when
you're tired and you're fixing lots of bugs when you're awake.
But when you're sitting there bleary-eyed and trying to get your tenth test
to pass and it just won't pass no matter what you do, you
know it's time to quit. You have a real-time feedback loop that's telling
you "go home". After a while, you put two and two together and realize that
you're not really understanding the machine as much as you thought you
were.
Of course, if you're not as rigorous as you should be, you just stop writing
tests.
This week I watched a programmer who is normally incredibly fastidious about
testing give up on his tests, work tons of overtime, jang it, and endure the consequent
failure. I have done this myself many times when working overtime. I am
much less likely to test code when I'm burning myself out than when
I'm relaxed. It seems like the tests are just so much less likely to pass
anyway, so why bother?
The moral of the story is that crunch time really doesn't work in the small
any better than it does in the large. If a deadline looms in the near future
and it looks like we're going to need overtime to make it, I am going to
have to admit to myself and to my team earlier on that the deadline has
already been blown.
I wonder how many more times I'll need to learn this lesson before it
sticks.
*:
International guests: a gratuity of 15-20% is appreciated if you
enjoyed the service, and may be included with the check for parties larger
than 10.