Blog Stubbing and Refactoring

Sometimes I have an idea for a blog post, but it's not a good time to stub it out. Maybe I don't have my notebook, or I just don't have time to do more than jot a placeholder. Sometimes in those cases I will open a new blog entry and put in a title that summarizes the idea. Later I will come back and start writing under that title, trying to retrace my thoughts and produce the post that was waiting to be born.

More often than not in these cases I ramble for several paragraphs and never quite manage to recapture the sentiment that inspired the title. Eventually I close the editor in frustration, feeling like I failed my muse. I feel like the title was the true name of my post, and I have failed to honor it.

This is probably not a healthy or effective way to write.

I don't follow this cycle with code. Often I will run up against a blob of functionality that I know I don't want inline. I have a rough idea of what the responsibility of that blob is and what parameters are required, so I stub things out. I make an interface, give it a function with the expected signature, then continue on using it, knowing I will go back to implement later.

But often when I come back around to flesh out the stub it turns out I was wrong about what exactly it would do, or--more importantly--what context would be required to accomplish it. But in these cases, I don't just keep laboring under the ill-informed constraints I set before. Instead, I refactor. I change the name. I add the parameters I need. I update the tests for the call site, and the code there as well.

In programming we name the thing to represent what it does. We don't build the thing to fit the name. In programming it is not possible to accomplish something without the necessary preconditions, so if they aren't present we adjust course.

In programming, we must rework.

So, too, in writing.