Sean and I got to spend a whole day going mad over the bug that we thought we squashed but, as it turns out, was not ready to die so easily. It was a heroic effort, full of sleuthing and more than a few leaps of logic. Most non-programmers see the job of a programmer as this almost mechanistic, yet wizardly manipulation of ones and zeros, where we understand absolutely everything that's going on under the hood, though how we do it is a mystery. Well, I love to ruin a good mystery, so I'll just come out and say that most of the time, we don't have a clue. The ones who really think they have it figured out are dangerous. As Socrates pointed out a while back, true wisdom is knowing that you know nothing. And I think if I was asked to pick one metaphor to describe a good programmer going on a bug hunt, it would not be that of the car mechanic who can hear a rattle and know the exact part in your engine that's malfunctioning. Rather, it would be that of a psychoanalyst taking intuitive guesses, based on the latest theories of the brain and several years of anecdotal evidence from previous patients as to what's wrong with the current one.
Would a bug really be a bug if you could tell exactly what's wrong by examining the visible symptoms? Sometimes it's that easy, but more often than not, these things are hidden under layer after layer of logic, often from hundreds of different brains, spanning several years of construction. If you were to go after it in a completely systematic fashion, it would take forever. You simply can't examine every bit of logic and understand it at a level where you can follow it like the machine does and still keep your sanity. So you make a hypothesis, check whether it seems to lead you in the right direction or takes you into a wasteland of despair, and if it's the latter, you do your best to come up with a new and better hypothesis to get you back on the path. In my mind, good programmers don't have easy answers as much as they have ever improving intuitions.
The bug here turned out to be an unforeseen side effect of spam prevention. Yep, that was it. It reminds me of reading about NASA losing a satellite for nine months because someone took a single, seemingly useless, flag out of the code. But we prevailed, and I got to see more system level automated tests in action, which was pretty interesting once we got into it. For some reason, as we dug further and further into the testing framework, dubbed "Cucumber", in order to figure out this particular bug, my brain kept making the connection to pickles (I don't really like pickles – I see them as "failed" cucumbers), and then I kept on thinking of the guy on YouTube who electrocutes a pickle in order to demonstrate what your life will be like as a true believer. The demonstration kind of freaks me out, but according to him, it's a good thing because it makes the pickle stand out from other pickles. Of course, this was probably all because it was Friday and strange things happen to one's mind on a Friday.
Nevertheless, we prevailed, the bug was slain, and the heroes entered their weekend victorious. That is, until someone finds another way to break the process and we're back to scratching our heads and trying to rehabilitate failed cucumbers.
This is probably the most paired programming I've done at a company, and although I often like to work alone, especially on anything creative, I find it's a great way to learn and a great way to focus. There are also pitfalls. I think you can sometimes lead each other astray via too much group-think, whereas you might think more critically on your own, but the advantage is that when you have no clue what to try next, usually the other person has an idea, and vice versa. And even a thousand miles away, after a whole day of wracking your brains out on something like this, it seems perfectly logical to give a high five for a job well done, even if it's a virtual one.
That's it! Have a good weekend. And may your dreams be free of menacing code.