Friday July 23, 2004
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.