Avoiding "the stupid hour"

From time to time there is a romantic notion of teams pulling crazy hours and working all-nighters frequently. The idea is that you can cheat the night (or morning, for that matter) and continue coding, writing, or doing whatever it is you that you do. Sometimes this is driven by maniacal managers, but other times it comes from within.

Now, I've already written about the occasional flashes of insight which lead to a late evening here and there. That's something else. That's where you have a fire burning inside of you and you need to get that fire routed through your fingers and turned into code. You don't do this often. It's just when things get really good and all get flushed into the computer at once.

This is more about the relentless push to keep working night after night even when there's nothing special going on. Enough has been written about it, but it always seems to get really complicated in how it's described. I want to give it a simple name that anyone can remember and anyone else can understand.

I call it "the stupid hour". When talking about myself, I call it my stupid hour. It's the point when I've been awake for too long and anything I create is sure to be suboptimal. The late hour has drained enough out of me to where I turn stupid and my output shows this.

In my younger days, I used to feel this coming on and would just keep going. This was a spectacularly bad idea. The next morning, I'd get up and look at the code and would have no idea how it ever worked. A function I had written during the stupid hour might work for a specific test case, but I would have to sit and really dig at it to find out how. Then I would also discover that it didn't cover other test cases, either.

Since it was ugly and unmaintainable code, it needed to be fixed. The fact it didn't even work properly also meant it needed to go. More often than not I'd have to rip it out and redo that particular chunk of code. It was a net loss of time. I should have spent that time the night before just sleeping rather than trying to fight it while coding.

In recent times, I've grown to recognize this and appreciate it as a useful signal. I tend to stop earlier than I would have before and switch to other things after a certain point. Why write something that will have a good chance of being broken and will require an immediate fix? Leave it as a "to-do" item and come back to it the next day.

There's another good point to doing it this way. Have you ever come back to a project and been unsure of where to get started? If you had left off just one item sooner the day or week before, you'd already have a known starting point. Write it down on a post-it note and stick to your monitor, then go do something else.

The next day, not only will you have a nice place to resume, but you'll also have the benefit of several hours (or days, if over a weekend) of subconscious/background processing you didn't even realize was going on. It'll make for a better result overall.

Don't feed the stupid hour. It never ends well.