The Machine is Sick
When I have computer problems, as I often do, my usual response is somewhere on the spectrum from frustration to anger. This usually works pretty well as a motivator. A few months ago, I called a friend and told him that I was chasing down a subtle bug and it was difficult to keep up my motivation. “Michael,” he immediately told me, “You have to name it.” So I did. I picked a name more or less at random, and immediately I was emotionally ready to go again. Fred was not going to keep me down. I was going to get him if it were the last thing I did. I had a correct code by the end of the next day.
I anthropomorphize things quite easily, but most people do so at least almost as much as I do. Step on a Lego brick and see if you don’t automatically ascribe some amount of malice to the object. Meet someone with a beautiful dog and see if you don’t immediately ask its name. We can’t avoid anthropomorphization – and, as I just mentioned, it can be a powerful emotional tool.
That said, if you adopt a combative paradigm, you must be prepared for the moments when the machine gets the best of you. When you’re writing code, this isn’t so likely: if you know what you want to do, you should eventually be able to do it. But there are other types of computer problems. Yesterday, my laptop refused to boot, to the point where even a full OS reinstall failed.
OK, fine. I tried the same paradigm. We have a gnarly issue. Start by naming it. That’s not so hard. I already name my computers; this one is Piper. (Long story.) Piper has decided to fight me today, and it’s a fight I plan to win. But, as I tried dozens of different boot parameters, kernel versions, and driver setups, I began to feel exhausted. The thing about fighting a bug in your own code is that you can always put it away and do something else for a while. You can’t do that with a total system crash. Almost anything I might possibly want to do at work, and lots of what I want to do at home, either has to be handled using half-remembered cloud passwords on a slow library computer, or it has to go through Piper.
Four hours in, I went to get a glass of water, and on the way I realized that there was another way to think about it. Piper didn’t hate me. It was just sick, very sick indeed.
Well.
We can’t let that be the end of that story, can we?
Two more hours and I had the problem isolated and a fix in progress. I lost some data of sentimental value but everything I actually want to do should be ready to go soon. All in all I’d call that a success.
To be clear, I’m not advocating for hospital decor around IT helpdesks. Piper was not actually sick – it didn’t even have a virus – nor was it evil. It was, and is, a dumb machine. Humans, however, aren’t really good at dealing with dumb machines. We can to some extent, but eventually everything around us gets a limited sort of personhood. My claim is that this is not a bug in our own reasoning but a feature. By using it properly, we can motivate ourselves to solve difficult, tedious, or hard-to-understand issues. Consciously writing the most useful narrative can keep you going. And you have the freedom to write it however you want: the computer isn’t going to dispute it, after all.