The Frustration of Computer Illiteracy and Obliviousness
Or, “Things that make me want to throw my hands up in the air and run around in circles screaming.” Also known as: “For the love of the gods, people! What’s obvious to me should be obvious to you too!”
So I have been re-discovering lately how much of what I do every day is based in investigation and experimentation. I am often not certain of the precise and accurate answer when I am asked computer questions by colleagues and end-users (otherwise known as “customers” in the parlance of the progressive and/or politically-correct wings of the business-influenced IT world). To determine more precise answers than “I think it’s X because I read about something similar in a tech blog once but I’m not really sure,” I investigate and experiment.
I investigate: I search Google, and manufacturer websites, and software help files, and blogs and discussion groups, and product forums. I ask on IRC and look things up on PSU’s user support site. I call colleagues at various help desks and IT departments around campus.
I experiment: I test the software or file in question. I look at information about the file available from the operating system. I open the file up in a different program to see what changes. I turn to the Unix command line to try using its ur-tools to excavate more relevant and telling details. I try different file formats, sizes, names, fonts, encodings, locations, etc. Eventually I try work-arounds like re-creating the file or reinstalling the program without all the options turned on or from a different machine on the network.
These techniques and skills are part of the foundational learning I gained by studying information systems and computer science for 4+ years. There were so many assignments where I was given a task and I had to understand the task before I could understand how to solve the problem the homework asked me to solve.
For example, part of the assignment might be opening and closing files on a Unix system. To do that programmatically, there are concepts about handling files that you have to understand separate from how to implement the task in C (or C++ or Perl or Bash) code. So you find yourself 3 hours into a project with an error you don’t understand, so you have to backtrack and understand some fundamental you missed — and you have to figure it out yourself from resources you can find online at 2am, because your project is due by 5pm the same day.
I recognize experiences like this gave me the skills to do what I do today — and that PSU pays me to do these things because I have these skills — and yet I am still constantly surprised at how little so many people seem to be able to complete a basic Google search, or try a basic change to what they’re attempting, to find out basic information about the problem they’re having. As the snide reply in the #cschat IRC chatroom went, GIYF (Google Is Your Friend) or or JFGI (Just Fucking Google It — a modern cousin to RTFM, Read The Fucking Manual).
This far into my essay/diatribe and I realize that there are situations where even competent, intelligent people probably shouldn’t be expected to JFGI for the answers to their computer problems. They really do need an expert.
However: when I am sent an email requesting I replace a .jpg image file on our website with a replacement image the sender has attached, and the attached file is an .rtf text file with a .png graphic embedded in it — all of which seems to have been created with neither a word processor or an image editor but with an outlining and diagramming tool, I kind of have to throw up my hands. It’s like:
We have this pickup truck in our fleet, see, but we want a different pickup truck, but we were unable to figure out how to order a pickup from the manufacturer so we ordered five extra-large wheelbarrows and had them delivered in the back of a station wagon, but we had the station wagon’s engine and tires replaced with a truck engine and truck tires, because we thought that would better suit our needs considering it would have to carry around five whole wheelbarrows WOW that’s a lot — so can you just, I dunno, install a plow on it or something and then put our company logo on the door so we can highlight our new fancy addition to our truck fleet in our next newsletter?
Sometimes, I get these little missives (usually one-liners so divorced from context and intent that it takes me a couple 15 minute phone calls or a half-day of back-and-forth emails to unpack the actual intended result) and I am at a complete loss as to where to start. Which question should I ask first?
- Do you know what a pickup truck is?
- Do you know what a wheelbarrow is?
- Do you know why anybody would use either?
- Have you ever actually looked at our vehicle fleet?
- Can you tell the difference between the different vehicles?
- Do you know how to drive?
- Will you go away for a few days or at least until I’ve had a stiff drink or much more caffeine so that your ridiculous, hapless, hopeless, helpless mewlings won’t cause me to collapse into a catatonic state or hysterically flip out and throw myself out the nearest window which is WITHIN ARM’S REACH SO DON’T TEMPT ME?
These are the questions that trouble me some days.
It leaves me feeling increasingly lost as to how to approach these problems some days. Do I try to educate the user? Do I merely ask, nicely, for what I really need? Do I ask for what I really need and offer to educate the user? Do I ignore it completely and put it off for a day, hoping it will make more sense when I come back to it?
Another way to look at all of this is that it reflects the relatively poor computer literacy rates among many people my age and younger who should know more and the abysmal computer literacy rates among older generations. I am like a reading and phonics consultant for a population of people who for the most part refuse to learn any more about reading or spelling or pronunciation than they already know. Actually, most of them don’t even refuse. They simply don’t even recognize the need to learn things. They use half a dozen software applications daily and don’t understand much of the basics of any of them.
Two things have occurred to me recently. The first is that there may actually be a reasonably large body of knowledge with which I am a ready expert. The second is that I do not think I have the first idea of how to teach anybody any of it.
As to my alleged expertise, I have spent so many of the last 6 years with people who knew so much more than I did — about programming, operating systems, system administration, web design, web programming, software applications — that I would rarely claim any real knowledge or expertise. Perhaps the average jogger feels rather pedestrian compared to a marathon runner.
But having worked outside that expert-rich environment for the last year or so, it strikes me that maybe I do have some expertise after all. Certainly there is no one else in the School that does what I do — although I still maintain that many of the people I work with could do most of what I do if they wanted to learn a little bit. If only they had the willingness to learn and someone knowledgeable to teach them!
But teaching people what I know, I am discovering, is not as straightforward as I thought. I have realized that there are so many niggling details to web page creation that it’s hard to present them in a meaningful, coherent, linear way. I have a bad habit of wanting to provide context to everything, and so I start about three steps farther back than people really need (egads just look at this post!). In conversations this is known as rambling, or giving three paragraph answers to questions that only require once sentence. In teaching, this is apparently known as boring and confusing your students way before you even get to the supposed topic they are trying to learn.
We have eight or so student workers who staff the front desk of our labs and resource library. They check out gear and teaching materials to students and faculty. And they try to answer computer questions for users of our Windows and Mac labs. But mostly they refer — to the help desk or to my boss and me.
One of the ideas that I presented during the hiring process for my current position was that I would like to have a role in training the front desk staff in our labs. Training improves the service we give, it makes our service more consistent, and it helps morale among both the staff and the users. It’s a win-win-win situation.
In eleven months, I’ve never given a training. I’ve explained or demonstrated a few things one-on-one to some of the staff as questions have come up, but I’ve never planned a full training or given one. Part of the issue for me is management support — I’m given some encouragement when I suggest ideas for trainings, but nothing beyond that — no planning, no scheduling, no specific feedback, nada.
The other part of the issue is I’m not sure how to approach a group of people with mixed knowledge and varying levels of interest in the topics I may teach. At the CAT, everyone was a volunteer, and people would be socially sidelined if they didn’t show some aptitude or focus on learning the material. At our labs, the staff is already hired, and their pay and positions aren’t dependent on whether they learn anything. (Really, they barely have to do any work — many of them spend their shifts watching anime videos on the web, with headphones if we’re lucky.)
The frustrations of dealing with the people on the computer illiterate end of the spectrum is ultimately the same mental barrier I face in attempting both to educate and to work with my colleagues. That mental barrier is my own — not theirs (they have other barriers). It’s the barrier of frustration and exasperation that I feel at situations where solutions — or even just approaches to gain more information — seem obvious to me, but to which many people are oblivious.
There are days, like today, when I don’t want to bother with these situations or these people. Days when my supply of tact is at a premium and my attitude is simply, “hey, obvious to me should be obvious to you.” Days when I understand and probably embody the brusqueness of some of my less-personable colleagues in IT — the ones the poor hapless users are always complaining about for being dickheads and assholes.
