Debugging and Programming AutoMike: Introduction
A couple of weeks ago I woke to find myself standing in front of the refrigerator, with the door open, rummaging through it for something to eat. When I say “I woke” up, I don’t mean that I had been sleepwalking, other than in the metaphorical sense. I mean “woke up” in the Sam Harris “Waking Up“ sense that I’ve written about before. I had been conscious. I had been aware. But I was not self-aware. My behavior was conditioned. It was automatic. It was in no way intentional. It was what I’ve called MikeSim and sometimes AutoMike. For this post, I’ll stick with AutoMike.
What AutoMike was doing was the opposite of what I intended. I had been trying to lose a few pounds, and having trouble doing it. I ate three modest meals a day, which should have been sufficient to have my weight dropping. But I kept eating between meals—and a lot of it was between dinner one night and breakfast the next day. I did it without intending to eat. I did it while intending not to eat. I was on the seafood diet. Whenever I’d see food, I’d eat it. If I didn’t see food, I’d go somewhere that I could see food. And then eat it.
I had decided: no more of that! No more wandering around and eating. And especially no more wandering around at night, opening the refrigerator, rummaging around, picking something and eating it. No more! I intended to avoid doing precisely what I was doing. I had made my intention explicit. I had not just instructed myself “don’t eat randomly at night.” But also “don’t go the refrigerator, don’t rummage around, don’t find things to eat, and don’t eat them.” Could any intention be more clear? And yet, I was doing what I intended not to do.
This was not the first time I had discovered myself violating my own explicit instructions. Insubordination was a way of life. In the sequence that leads to unintentional eating, I might wake up with food in my mouth. When I woke up then, I’d spit out. Sometimes I’d wake up too late—I’d already swallowed. Sometime I’d wake up earlier. This time I caught myself rummaging, prior to selecting, eating, and swallowing. I stopped. I stepped back. I closed the refrigerator door. I reminded myself that I did not want to be doing what I was doing, and turned to do something else. Which is what I always have done.
Then, for once, I realized how stupid that was and what was actually going on.
I realized that I had not gone to the refrigerator. I had not opened the door. I had not looked around. I had not been present for any of it. Until the moment I “woke up” there was no “I” to do any of it. Until the moment of waking, all my behavior had the product of my conditioning—or my programming, if you prefer. It was not Mike. It was MikeSim, or AutoMike—my conditioned self. AutoMike is a set of programs running in my brain that save me the trouble of being awake and aware. As I’ve written before AutoMike does such an excellent job that it fools most people into thinking they’re dealing with Mike.
And I did not really self-correct, either. I might have wakened for a moment, but the whole subsequent process: stepping back, closing the door, telling myself that I did not want to be doing that, turning to something else—all automatic. All AutoMike.
I realized that the unintentional behavior that led to me standing in front of the refrigerator, rummaging, despite the intention to do otherwise must have been because at least one of those programs that constitute AutoMike must have had at least one bug.
According to legend the term “bug” as a reference to computer problems dates to a story told about the pioneering computer scientist Grace Murry Hopper discovering that a particular computing problem was caused by a moth in one of the relays (relays?) for the computer. The predates computers and some claim it’s still in use rather than more accurate terms like “error” or “mistake” because we programmers make so many mistakes that we’d get depressed if we called them that. So we use the cutesy name “bug.” In safety-critical software, where such errors are intolerable they’re called “defects.” Bugs are cute. Errors are tolerable. Defects must be avoided and eliminated.
So it’s a bug—because I’m not psychologically prepared to view myself (or rather AutoMike) as defective. Even if it is defective.
I’ve made my living writing software. You write software by expressing a procedure that’s designed to carry out an intention. We’ll talk about the source of such intentions later. Take it as a given that there’s some intention. When the procedure produces a result that different than the intention, it’s evidence of a bug. You get rid of bugs by following a disciplined debugging procedure. I am good at debugging. So why not debug AutoMike?
That’s what I asked myself as I stook in front of the refrigerator that night. Don’t just correct the output. debug it. (The fact that the “correction procedure” was just another AutoMike automated procedure didn’t occur to me until I was writing this.)
I’ve done things—a lot of them—to try to change my (AutoMike’s) behavior when I havnen’t liked it. But I’ve never looked at it as a debugging problem. I’ve never pulled out my substantial debugging toolkit and applied the knowledge that I’ve acquired while finding and fixing thousands of computer bugs.
It’s not that I haven’t ever deliberately corrected a bad habit or deliberately created a new one. I’ve done both. But I’ve never gone about it methodically. I kind-of-know how AutoMike was programmed. I kind-of-know how AutoMike works. I kind-of-know how to add to AutoMike’s programming. But what’s the best way (for me, at least) to find a bug? What’s the best way to correct an error? What’s the best way to add to AutoMike’s programming?
So that’s a project that I have decided (with help from AutoMike) to work on.