Not that anyone has ever asked me, but what college course was my favorite to teach in my 8 years in academia, the last 5 as a junior MIS professor? A Human Factors in IS graduate course I taught at Illinois State as a visiting professor at Illinois State in the fall of 1990. Technically, ISU didn't have an MIS program--they had a hybrid applied computer science department. BB normally taught the class, but I believe she took a sabbatical year off to set up a research lab. The availability of the gig came to my attention from Jane Carey, an Arizona State professor who had organized an annual symposium in human factors I had regular attended during my last few years in academia. At that time, I was one of the few MIS professors with a research interest in human factors/ergonomics. I have to smile because a lot of people think human factors must be some kind of pop psychology course in interpersonal relationships. I had run into a similar misconceptions years earlier while working on my first Master's (in math); I bought a group theory book, and the bookstore clerk asked me what psychology class I was taking: too cute! (Groups are a topic in abstract algebra.)
I had come across cognitive psychologist Donald Norman's book, The Psychology of Everyday Things (later renamed The Design of...) /One of the things he discussed in his writings was the construct of designing for error. One of his stories I love to retell (and closely related in concept to the issue I described below) involved a word processing machine, before the emergence of today's PC writing software. He noticed that a key to delete a document was next to a carriage return/enter key. He told the vendor in effect this was an accident waiting to happen; he was sure that typists would hit the delete document key by accident. The vendor was in a state of denial and so they went to an experienced typist and Don asked if she ever hit the key by accident. "Oh yes, all the time." The vendor incredulously asked, "Why didn't you ever say anything?" "Because I had ben trained on the key's functionality and figured it was my fault."
A related incident I have often retold I think comes from one of Lynne Markus' books. I often have to struggle to maintain my exposure in saying it without laughing. I think it's an old MIT legend behind the idiom "ir's not a bug, it's a feature". The lab was testing a compiler, and one of the testers forgot to include an END card to his program deck. To their shock, the mistake resulted in unintended consequences, like wiping out memory or tapes. They dutifully reported the problem to the vendor. So after the vendor released the final version, the lab replicated the incident, to ensure the problem had been addressed. To their amazement, the same result happened. Stunned, they went to the documentation and found the following note: "Normally you would have to spend extra money to get a useful erase utility. We include one for FREE! It is also very efficient: you don't have to include a long program deck to achieve the desired effect."
I have worked on Unix/Linux systems since 1994. You normally have a cron scheduled job daemon running in the background. For an enabled user, you schedule a particular script/process to run per line entries of a specified time according to a a certain syntax in a crontab text file.
The salient point is, you normally edit your user crontab through "crontab -e" (and presumably your environment specifies a vi editor, and you edit using commonly known vi operations). I've probably edited crontabs hundreds of times over the years without incident. Now the "e" key is next to the "r" key on your standard QWERTY keyboard layout. Guess what "crontab -r" does?... Oh yes, I did. Do you think you get a warning like, "Are you sure you want to remove all your crontab entries?" Of course not. I accidentally fat-fingered my scheduled jobs.
I had literally dozens of scheduled jobs in my crontab and no local backup of the text file. Fortunately, my Unix system administrator had a backup. And of course the very first thing I did after restoration was to enter a vi command like :1,$w ~/crontab.bak .
One of the things you learn in the human factors literature is even experts make mistakes, although at a less frequent basis. You need to plan for human error. I seriously doubt in the future I'll ever modify crontab again without specifically first backing it up in an archive directory.
