Trying to find useful, relevant data in this rack was like trying to find a single page in a book 60 feet thick. In fact, that's exactly what it was, and even worse, there were dozens of indexes spread throughout the 60 linear feet of documents, one index could send you to another index, which then referred to specific pages, which might then refer you to updates or errata inserted erratically throughout the rack. When the room was busy, there would often be several people reading different sections of the rack, taking notes, then moving to a different section, taking more notes, etc. Some sections of the rack were more useful than others, and it was common to see people standing in line behind someone, waiting to use that section of the rack.
There were only a few people who knew the entirety of the documentation, a few Comp Sci grad students who had to maintain the racks by inserting the monthly updates and errata. It must have been extremely tedious to insert updated pages throughout the 60 foot rack, but in the process, they learned where all the useful information was.
These same grad students also worked in the "debug room," which was a small office where you could ask for help interpreting your program errors. People would line up in the hall outside the office, waiting to seek advice from "the debugger." The debugger had a short rack on his desk containing a master index of the big 60 foot documentation rack. He would look at your program printout, and if the problem was not obvious, he'd look through the index, and refer you back to a specific document in the big rack. Then you'd go back and read some more documentation, figure out what went wrong, then you'd punch a few cards to correct your program error, search through your card deck to switch a few cards, and resubmit your program. And the cycle would start all over again.
The one thing I remember most vividly about the debug room was a big sign hanging on the wall, it was the first thing you'd see upon entering the room. The sign was written on a computer pen plotter, in an oddly machine-like character set, it said:
Computers never make mistakes. All "computer errors" are human errors.Even today, this is the hardest thing for computer users to understand. If a computer does not give you the results you expected, it is because you gave it bad instructions. Computers follow your instructions faithfully, and will accurately produce the incorrect answer that you incorrectly specified. In those olden days, computers were not so fault-tolerant, if your program had errors, it would stop and produce nothing but an error message. But modern computer programs anticipate that their users might be idiots, and are designed to gracefully handle even the most stupid, nonsensical requests. I suspect this is a very bad thing. It allows people to get results even if they are imprecise. I think it would be better to be strict, returning no results in response to vague inputs.
At the risk of offending a dear friend, I will use him as a case in point. I have a friend who often asks me for technical support, but his phone calls sometimes take hours, primarily due to his vague descriptions of his problems. He'll phone me up and say things like "I'm trying to print, but I press the whatchamacallit and nothing happens." No, I'm not using the word "whatchamacallit" as an euphemism, he really does say "whatchamacallit." When I object to his vague descriptions, he says I'm supposed to anticipate what he is doing because I know the programs so well. This is precisely NOT how to get good help. If I don't know precisely what you're doing wrong, how can I tell you how to do it right?
To use a computer and get good results, you must operate it with precision. But first, you must think with precision. This is no different than any other complex task in life. Human beings are not used to thinking with precision. This is why it is easier to fix computers than to assist users in operating them. Computers always give you a precise report on what they are doing. Users often don't know what they are doing.
After decades of providing tech support to thousands of computer users, I made an observation that I have formulated as a new law, I call it "The Law of Infinite Stupidity." It states:
There are a finite number of ways to do something right. But there are an infinite number of ways to do something wrong.