Unit Testing Saves State

As others have pointed out, it takes a while to get into the coding zone. Thus, once I'm in the zone, I try to stay in it as long as possible. Often, this means I code until exhaustion. That is, I keep coding until I feel too tired to competently continue.

I don't do this out of machismo -- that's what MacHack is for (grin). Instead, I do it out of efficiency. Getting back into a project after you've lost state consumes a lot of cycles.

One of the beauties of unit testing is when it fails. Err, when one of your tests fail. Typically, I like to get a project to a point where it's failing a test before I crash for the night.

You'd think I'd toss and turn all night because I have broken code somewhere. Fortunately, that's not the case. Instead, I sleep soundly, knowing the project has a gigantic sticky note posted on top of it in the form of that failing test. It's obvious what needs to be done next: get that test passing.

And stepping through a failing test is a great way to get back up to speed on the project. Class, method and variable names quickly flood into your brain, firing off neural links and bringing it all together again. The tested code is (re)written and the project is back in motion...

Update: John Blackburn informs me I'm not the first one to notice the power of an interrupted work to invite reentry:

Ernest Hemingway appreciated this also. It was his practice never to exhaust his writing completely. Rather, he would always leave a little bit unfinished, a bread crumb which in the following morning would let him come back up to speed quickly.

Sunday, March 16, 2003
12:00 AM