Across the line of Magic.
Programming is something thats an inherently fun affair. It lets you be the master of your creative energies. It lets you become god for some time, It lets you create. And that gives a programmer immense pleasure and satisfaction. Just like sex. And then there is debugging. The darker and uglier side of programming. Where you have to deal with the mistakes that you so blissfully overlooked when you were busy creating. The pleasure comes back as a pain to haunt you. Again, just like sex.
I have been busy hacking on a feed reader in lisp these days and trying to fix an XML parser into accepting something as brain dead as ‘CDATA ‘ and the XML parser was actively fighting back. Just like a wounded dog you are so trying to help but still bites you back. It was more of a debugging (pains) session than a pure programming (pleasure) session. I was at my wits ends, unable to fix the damn thing. My code to my eyes looked right and my compiler was conking out. It was like trying to fight an invisible enemy. The worst bugs to fight are those that are not in your code, but in someone else’s code. But this was not even that. It was what happens when induvidually correct programs are coupled and their interactions create a semantic monstrocity that its hard for even the creator to understand, let alone anyone else. This particular problem is what happens when you take an untested XML parser, SLIME, Emacs and SBCL and put them into a mixer and then try to figure out whats wrong with your parser. It turned out that SLIME uses a limited form of encoding called iso-8859-1 whereas most web transfers and the CDATA in RSS feeds are in UTF-8 type encoding. You think thats hard to figure out? – You bet it is! The problem is the other characters apart from your original ascii are mostly invisible. And hence vrey hard to even insert your timely print debug statements to observe what actually is going on.
One thing that definitely helps when you are debugging is taking a break. In fact, from my experience taking a well deserved break definitely speeds up your following debugging session. But in spite of this, like most other programmers I was caught in ‘fixing’ the bug that I was losing concentration and was basically getting frustrated. I knew I had to take the break, but I used each and every excuse to convince myself not to. But fortunately the bell rang and it was the TV repairman. This was when I started my journey across the line of magic. Now let me explain what the magic line actually is – every programmer has to learn one of the most important concepts in programming and is often exposed to it at the earliest stages in any good computer science course and thats abstraction . Abstraction is just a formal way of telling that you should stop bothering about the nitty gritty details and get to work on your problem. The level of abstraction depends on the nature of the problem and the programmer. In fact abstractions are every where and people use it all the time. Files are abstractions over the various device dependent process for storing bits onto storage devices. Your operating system is an abstraction over the raw hardware and your processor and so on. One characteristic of a good abstraction is that its as ‘not’ leaky as possible. Infact most good abstractions totally make invisible the underlying implementation. Files are good examples of those types of abstraction. And in general, us programmers should not bother about what lies beneath our abstractions otherwise we are doomed to the same fate as the web surfers of the pre-google era – information overload. But since most abstractions inevitabily turn out to be leaky there is no way but to break the law of abstractions. The question is all about where to draw the line. The line beyond which you trust your abstractions unqestionably that you don’t even bother to know how its working, but it simply works – like magic. And this particular line is what I call the magic line.
Programming in Lisp had recently raised my line from what it was when I was writing C code, and sometimes its just nice to find your roots. Comming back to the TV repairman, our TV had been busted recently due to the monsoonal rains and erratic electricity and no TV was something that was totally unacceptable to my ‘tv-serial’ addicted parents. So they called in a funny looking guy to fix it. Usually I hate doing house work, and espescially helping out TV repairmen and all that and to be honest I din’t take this guy too seriously in the begining, but there was something that just din’t fit in about this guy. So he started to work on our TV and then I saw this look on his face. I have rarely seen this except on a few close friends of mine. The last time I saw it on a guy’s face the guy was working on implementing minimax trees and alpha-beta search. Did I say implement? Let me make a small correction. He was trying to debug it. This look, which I had considered the secret trade-mark of us elitist geeks, was exactly what I saw on the repairman’s face. This was obviously an expert at work. And the best way to learn anything is to learn by watching the experts do it, and this time I had to cross my magic line to the realm of bits and piecies and all your fancy electronics – the resistors, the capacitors, the transistors and what not. And very soon it dawned on me that he was in a similar predicament as I was just before he had rung the bell. Fixing a system where the bug is in the connections rather than the components themselves.
And he debugged the system beautifully. My words don’t do justice to the skill of this expert, but anyhow here is my feeble attempt to describe it. As usual he started with a problematic system. There was no output on the CRT, no sound from the speakers nothing. For all practical purposes the system was dead. He started out by pulling out all plugs, and all the other things that hold the tv together, he was taking apart the system into its individual pieces and took a good look at the whole system. the main PCB, the CRT connectivity boards and the audio subsystem. I guess he took a moment to understand the complexity in its whole. Then he went about looking at all the usual sources of problems in TV system, and incredibly his first guess was right. It was the power subsystem that had been totally busted. He took out the old power system and replaced it with a new one. And walah ! – the system still didn’t work (got you there didn’t I?). Now this is where the whole process gets close to what real debugging is like. He was poking around with a multimeter and various points and once he found something was suspicious he tried to unsolder and try the system again. He did this for various components, unsoldering and soldering them back. At some point he even inserted new components (a resistor to be precise) to circumvent a diode that he was sure of being broken. And with the diode he added a couple of buffers and a weird three legged device which I won’t name as I won’t risk my knowledge (or lack thereof) of electronics being exposed here. Seems so close to all those gartituous print statements that I litter in my code when debugging. And once he got a reading on the multimeter I saw the “Aha!” look on his face. Seems like he had finally nailed the bug and in fact he did. He replaced the faulty component (which I presume is a diode), with a new component and the system sprang to life albeit with a grainy picture and almost indecipherable sound. Now, there is a difference between real debugging and his method. We programmers might have let it go and left it for version 2.0, but this guy didn’t stop. He twiddled with various controls, some resistors changing one component for another until the picture was clear. Next he worked on the sound system and he got it working in no time. It took him one painstaking hour to fix our broken TV form dilapidated old hag to “good as new” condition and he was working for minimum wage. Now thats India for you. I paid the equivalent of what a boy would get for one hour’s work of delivering pizza in the US to watch an obvious expert at work and without the complaining too!!.