Late Night Coding

Brent writes about “Why I Don’t Code Late At Night Anymore.” In point of fact, I’ve made the exact same mistake he describes. Daniel Jalkut nods.

I used to do a lot of coding after midnight, back in the day, but I used to stay up to all hours nearly all the time. Linda’s a big believer in sleep, though, so I don’t do it much any more.

But I think Brent is mistaken when he blames this mistake on the hour.

I would have realized this had I been fresher when I wrote that code. But it was late, and I thought I was being smart.

Brent is pretty sure he would have realized the problem. I might perhaps have seen it coming – especially after the first time I made this mistake.

Making this kind of mistake can make you a better programmer. Over the years, I’ve known a very few programmers who really didn’t make mistakes. They saved themselves a lot of time and bother. But somehow they also ended up working in software backwaters or working outside of software entirely.

Mistakes generally – and this kind of mistake specifically – have been the great driver of software progress in this generation. Just about every advance in practice is connected to this sort of logical error. The tiny-method style of object-oriented programming specifically addresses it. So, too, does the Template Method pattern, which we would write for Brent’s case:

- (void) removeThings
 [self willRemoveThings];
 [self removeTheThings];
 [self didRemoveThings];}

This is a catechism. Whenever we do something non-trivial, we ask:

• What needs to be done before we start?
• What needs to be done?
• What needs to be done after we finish?

Test-driven development or assertion-rich development or promises add some additional questions:

• What needs to be checked before we start?
• While we're working the problem, how might we know that something is amiss?
• What can we guarantee after we’re done?

Where once we would have done a lot of work in a big modular subroutine, now we break it up into a bunch of methods. Then we break those methods up into smaller template methods. And then we break those methods into little methods. Eventually, we have methods that can’t possibly fail.

Now, you might expect this to lead to disaster, to being swamped by thousands and thousands of little methods. It turns out, however, that a surprising number of the smallest, simplest, most numerous methods are likely to be used all over the place. Once you have them, these methods encapsulate abstractions that make the code cleaner and simpler, and that reduce clutter. In practice, things settle down.

But the driving force is always the fear of the third act: there was one thing they had forgotten. If you don’t make late night mistakes, I think there's a chance you never get there.