It's All in How You Look at It

You should have picked up by now that solving problems in the computer world takes a certain kind of mind set. You have to be able to see problems the way that computers do. They are incredibly stupid machines. They can't do anything more than what humans have told them to do. When a computer gets uppity and gives us a hard time, remember, it's nothing but bits of silicon, copper, and plastic dumbly following the instructions that people have given it. At bottom, there is nothing difficult or magical about it. It is straight and simple logic: if this event occurs, then do this; if it doesn't, then do something else and do this until that becomes true. Pull the plug (reboot) and most machines will go back to behaving themselves. (And the first question tech support usually asks is: have you rebooted?)

In my first high tech job after six months of working swing shifts in operations, mounting tapes and clearing printers, I had had enough. A temp position opened up in user support and I jumped at it. Now I got to deal with the people side of computing, not just the machines. It didn't take long to figure out that if people would leave computers alone they would perform much more efficiently. There were two aspects to my job that over-lapped: supporting users and evaluating credit requests.

In those days, people did not own computers: corporations and governments did. It's not many people who had a few million dollars to spare just to add columns of figures and issue invoices or to perform some arcane mathematical calculation. So computer time was sold in a system called time sharing. (Sounds suspiciously like a certain condo ownership arrangement at a holiday resort.) People as individuals could not afford to pay for time on these monolithic machines, but, their employers and departments could.

So, the first thing most users did when their programs failed was call tech support (namely, me) and try to blame a mainframe error for their problem. Despite their experience, most never did figure out that machines don't make mistakes. My first question always was: what have you changed since the last successful run? They always swore they hadn't changed a thing, at which point I would ask to see their code. It would come to me in the form of fan-fold paper print-outs, some of them several inches thick. I would have to step though the code, line by line, until I came across something absurd. I'd telephone the user and tell him to look at line such and such: it didn't make sense. That's when I would get the truth: Well, I didn't think that one little change would cause the whole program to crash. Goren, the TV detective on Law and Order: Criminal Intent, has expressed the belief that all people lie. He must have worked in tech support at some time.

The other aspect of my job was to evaluate credit requests. When users thought that their computer time was wasted because of an operations error (such as mounting the wrong tape or unintentionally aborted a job prematurely), they would fill out a form requesting that the cost of that run be refunded. We never gave them any real money, just credit against future runs. I'd have to decide if a botched job was the fault of the user or of operations staff, and then fill out another form with my findings. That form would then circulate through department heads, each initialing it until it was either approved or disapproved. I had to ensure that the forms kept moving through the system which I did mainly by pestering. I kept two copies of the forms: one of the original request and one of the final approve decision. No one before me in the job had tried to create any sort of filing system other than dumping all copies of the forms into a drawer.

This, I thought, was ridiculous. I would never be able to find an old credit-request form if, for some reason, I needed it. And why were we using so much paper? It didn't make sense to me in a large computer centre that we were using carbon copied forms.

So, I proposed and won approval to computerize the process. I wrote the code. Now that users could apply for credit requests online, I could review their requests, tick an "approved" or "disapproved" box, and write up my findings on the computer form. An email would then be automatically sent to the various department heads to let them know that there was a credit request awaiting their decision. If they didn't tick off their box on the computerized form within 24 hours, they'd get another email--and so on until they finally ticked Yes or No beside their name. Once all the required approvals were complete then accounting would get an email advising them that there was an approved credit request awaiting their action. They too would get automatic reminders until they dealt with it. Whichever way the decision went, the user would be informed by email.

All done by machine with minimal human interaction. Now no credit requests would get mislaid and there was a history of all credit requests permanently available to anyone who needed it. I no longer had to pester department heads to move on the credit requests on their desks. Computers are very good at pestering. And, I got to shred a drawer-full of useless paper.

It's all in how you look at it.