So hot, I was stopped by security

The recent heat wave in Singapore, and the unfortunate H1N1 epidemic reminded me of a story. I’ve only told this to a few people, but here is where you’ll read about the full story.

It was slightly later than the SARS period. People were frightened of getting infected. The basic detection method was the temperature check, so thermometers and heat scans were employed.

I was also looking for a potential job position, and I got an afternoon interview with a company. I arrived early because the location was a bit remote.

Now, it’s a habit of mine. Whenever I know something important is happening later, I stop drinking. Just so I won’t have to go to the bathroom at the most inopportune moments. I don’t know why, it’s just a personal quirk.

So I was walking from the bus stop to the company’s location, under the hot sun, in long sleeves and pants (thankfully no suit and tie needed), and heated, slightly sweaty and parched. It was a wonder I reached the security guardroom of the company not dripping wet from my own sweat.

Now this company had a very high security level. They had a full temperature head scanner. They had this device that scans people, and a heat map shows up on their screens.

Well, it was after the SARS period, so I could understand their security concerns. Someone from the company was waiting for me. He waited by the side while the security guard asked me to stand at a designated spot. Then the guard activated the scanner.

Apparently, my temperature scan looked like a sunset with lavish swathes of reds and oranges, because the guard told me to stand still again while he scanned again. Sensing something wrong, the adrenaline in me surged a little, which didn’t help cool down my body temperature. I held still. I even held my breath. I still failed the temperature scan.

The company liaison, surprised by this unexpected unfolding of events, took me to the inner parts of the guardroom, where the air conditioning was stronger. He also offered me a cup of water from the dispenser. Then he told me to sit and wait for a while first. I got myself a cup of water, drank and accepted his suggestion.

“I’m gonna fail the interview before I even step into the company office, aren’t I?” silently and matter-of-factly entered my thoughts.

After 15 minutes (or half an hour, I didn’t keep track), I stood up, and took the temperature scan again. I placed my feet at the exact position of the designated spot, shifting my shoes to fit the exact outline of the pre-drawn shoe print. My hands were held in a limbo of alternating tenseness and forced relaxation. I looked up as confidently as I could, keeping my breathing steady, taking deep breaths… And the guard scanned.

What took seconds felt like the time passed while running around a 400 metre track 2 times, then jumping into a pool to swim 100 metres and then work out a 6 digit long division. By hand. I was getting ready to dive into that imaginary pool in my mind when the guard said it’s ok. I passed.

The company liaison, obvious relief on his face, took me into the company proper. And the interview itself? Well, it’s not as interesting as the guardroom episode… alright fine, I’ll tell you about it some other time.

Telescopic and infrared vision

When you debug code, you shift between two modes, telescopic and infrared. When you’re pinpointing errors, you’re in telescopic mode. When you have no idea where’s the error, only that there’s an error, you’re in infrared mode.

Telescopic vision

With the advancement of compilers, syntax errors are becoming easier to spot. Chasing down that elusive semicolon is a thing of the past. I learnt to code in a text editor. On a Unix machine using the vi editor no less. I didn’t get syntax errors until I compiled my program. I didn’t get segmentation faults until I ran my program and found out I hadn’t malloced enough memory for my matrices.

So I was very careful with syntax. Every = sign and == signs. Every ;. Every * for pointers. With monochromatic editors, no squiggly lines and no Intellisense, I developed hawk-like abilities to spot syntax errors before the compiler does. With practice, this extended to even logic errors. The compiler cannot tell you if

int i = 4 + 5;

is correct or this

int i = 4 * 5;

With modern compilers, simple syntax errors are caught easily. Now there’s a different problem, embedded code. Specifically, SQL statements in a string variable. For example, the compiler can’t tell you this is an error

comm.CommandText = "updte WrongTable sett columdesc = you rock' wear user_id='beerkeg'";

You’ll only know something failed when you run the code. Unless you have telescopic debugging skills of course.

Infrared vision

Do you know someone who can “feel” a spelling mistake a mile away? Do you know someone who can read paragraphs and paragraphs of text, and then singling out phrases such as “please bare with me”, “just loose that pen” or “that man is stationery”?

They have infrared vision. They see a blurry image and something in the text just doesn’t seem right. Their “spider sense” tingled and they just stop at that error.

Expert programmers do the same thing. Since syntax errors are highly unlikely (because of modern compilers), that leaves subtle coding quirks or logic errors. Somehow, something about this chunk of code doesn’t feel right…

int i=0,sum=0;
for(i=1;i<=10;++i);
sum+=i;

The inexperienced programmer would be looking at sum += i; and wondering why sum doesn't contain the sum of the first ten integers. The expert programmer would be wondering about the use of adequate whitespace, why the for loop doesn't use curly brackets, and why the for loop ends with a semicolon... hey, that's the error!

Getting super vision

The thing about telescopic mode is that you get tunnel vision in the extreme case. You blithely ignore large parts of code and focus on a line of code which may not be the source of the error. And you spent half a day wondering why that line of code isn't working. It is. It's the other parts of code that gave the wrong context, and so as a whole, that chunk of code doesn't work.

The thing about infrared mode is that everything's blurry. To make sense of things, you need to have some experience in recognising recognisable stuff. Such as automatically checking the structure of the for loop for the 3 parts (initialiser, terminator and incrementor). The operative word is "automatically". It doesn't do you good wearing infrared goggles in the jungle and spend 5 minutes figuring out that, yes, that bulbous reddish-orangish mass is a human (and not too friendly at that). So it's no good stopping every so often while scanning code.

To get better at debugging, you need to learn to combine both. Use the infrared mode to scan lines of code. Stop briefly when you feel something's not right. Switch to telescopic mode to find out why you don't feel right. If you find any error, go ahead and correct it. If not, switch back to infrared mode and continue scanning.

This gives you the advantages of quick scanning and the tight focus of pinpointing.

Of course, this is terrible if you're just starting out with zero experience, and scanning means you'll miss obvious errors because you're not trained to recognise them. Good news is, the more code you write and debug, the faster and more automatically you can scan, and the more obvious errors look to you. With practice, you'll also recognise good code faster too. This is important because much of what you read will be good code (or at least it'd better be...), and you need to quickly decide that it is good code and continue scanning.

So do you have both telescopic and infrared vision?