ALA TechSource Logo
 
curve Home spacer Publications spacer Subscribe spacer Blog spacer About  
    

Asking Why

Submitted by Kate Sheehan on August 27, 2010 - 9:47am

Anyone who has spent time with small children knows that "why?" is one of the best and most vexing questions people can ask. "Why?" probes for motivations, explanations, understanding. It demands reflection and clear communication, and I think it's safe to say that most people have a complex relationship with this tiny word.

Library techies can leverage "why?" to change how their organizations operate by questioning a ibrary procedure. Discussing workflow with coworkers and asking "why?" a lot, while offering ways to automate procedures, can offer value to your colleagues and your organization (and maybe wreak a little havoc). But "why?" is also a question library techs sometimes dread. "Why did it work before but not this time?" "Why is it broken?" "Why am I getting this error message?" Often the answer is straightforward: a setting has been changed, or a network problem is creating the error. But sometimes, getting to why would require an electrical engineering background and a path of inquiry beyond simply fixing the problem. Nothing is quite so frustrating as resolving a persistent error only to have your techjoy smashed to bits by a coworker disappointed because you're not quite sure why the computer stopped recognizing the printer, you only know that they're now friends again.

Before you all send me angry email: yes, most of the time, knowing why something isn't working is the key to fixing it. Computer not connecting to the Internet? Well, that frayed Ethernet cable might be the culprit. This is the third time in a year that's happened? Well, maybe we should move the cable out of the path of the vacuum. Why did your computer's Ethernet port stop working? No idea. It's dead, I installed a network card, now you're online again. If it dies again, that's a different story. A lot of troubleshooting is looking for patterns, waiting until cause and effect can be established reliably. A one-time problem doesn't always merit a full-out investigation into what runtime error number 37 means. Most IT folk seem to have a stock phrase or two: "Let's assume that it's just a hiccup, but call me if it happens again."

We can be, however, a teeny bit hypocritical about this. We get annoyed with the "why" we can't answer, but grouse that our less technical colleagues don't understand why their actions can cause problems or why their ILS doesn't work when the internet is down, or why email that's already downloaded to their computer won't show up in webmail. We want them to take our fixes on faith and also posses a clear understanding of how their network is set up.

The people who ask "why" could be the most likely to end up understanding the library's technology and the most willing to be advocates when everyone's wondering why you haven't yet fixed a big problem.

I am loathe to use a car metaphor, but it is apt. My favorite mechanics have been those who happily explain what was wrong with my car despite my rudimentary understanding of the problem. My most favorite mechanic once handed me the broken down part that was making that noise and showed me the healthy replacement (my car was up on the lift). Honestly, they looked the same to me, but I so appreciated the time he took to show me what he had done. He wasn't trying to prove anything to me, only explaining. He also clearly loved what he did and was excited both to have tracked down the problem and saved me from a horrible car accident. (It was a "you're lucky you didn't go on the highway last week" repair.) Other times when he told me he didn't know the cause of a  problem, I didn't mind because he had explained when he did know.

Most of us have had a mechanic or a doctor or someone with greater technical knowledge make us feel small and stupid and dense for even asking for an explanation. The people we return to are those who draw a quick sketch or use an analogy or simply take the time to tell us what's going on.


Comments (4)

@effing.librarian,

@effing.librarian, non-techies are notoriously unreliable narrators when it comes to describing what they were doing just before things went bad. I'll still ask, just out of habit, but I've learned to take the answer with a grain of salt and run through my own personal procedures.

As for explaining what the problem was, my answer is tailored to the person asking the question. (And a lot of people--staff and public--don't want to know.)

Doctors who draw pictures are

Doctors who draw pictures are keepers, Candy! I know people who like to watch YouTube videos of procedures before undergoing them. That's a little stomach-churning for me, but I like diagrams. Not only is the explanation reassuring (librarians, after all, like information), but I'm also calmed by the idea that I'm dealing with someone who understands the situation well enough to explain it to me.

wow. I must be around

wow. I must be around computers way too much. I rarely use "why" questions. I say, "I was spilling tea on the monitor when it went smoky. Fix it."

And I ask, "what are you trying to do?" or "what were you doing when that happened?" when I'm trying to figure out how ot help someone.

(and your captcha test expects me to know how to spell??)

I will never forget the

I will never forget the doctor who drew in pencil on the paper bedsheet a picture of my toes and what a Morton's neuroma was, and exactly what he was going to do. Like your car mechanic. My dentist is the same way - no I don't actually understand the technical details, but I am much assured by seeing the x-rays and having him diagram exactly what will be happening. "I know it looks like the nerve is close to where I will be working, but to me it's miles away, honest".