I’m thinking about Meredith‘s survey again this morning. In particular I’m thinking about one of my responses to question # 4: What skills and competencies do you think are most important for librarians to have today?
In answering this question, one of my replies had to do with troubleshooting. As libraries add more electronic resources, new online services, and more computing facilities, troubleshooting and technology problem-solving skills become more and more important.
However, even though I gave this answer within the context of a survey on library education, I don’t know how easily troubleshooting skills can actually be taught. With many troubleshooting issues, intuition, instinct, and gut feelings all play a part.
Of course there are certain things that people can be taught to check systematically. But this is only one part of troubleshooting, and those who rely exclusively on a list of steps are somewhat akin to a telemarketer sticking to a badly-written sales script.
Consider some of the steps in troubleshooting a problem with an attached printer. Many things are both obvious and easy to check.
Is the printer plugged into a power source?
Is the printer connected to the computer?
Is the printer turned on?
Does the printer have paper?
Does the printer have toner?
Is the printer displaying any error lights or codes?
Moving beyond this initial list, there are still a number of basic things to check.
Is the application sending the print job to the correct printer?
Has anything changed on the computer or has anything new been installed recently?
Does Device Manager (for Windows users) show any hardware errors?
Is the correct printer driver installed?
Is the printer driver up-to-date?
Does the printer work properly with another computer?
Does the computer print properly to another printer?
Is there any sort of local security software that might be interfering?
Having exhausted the obvious possibilities, that’s when troubleshooting has to get creative.
Can you print a document from another application? I once saw an odd problem where a printer experienced memory overflow errors when trying to print PDFs, but all other document types were fine. the manufacturer’s official solution was to lie to the printer: tell it you’re using a different model, and that solves the problem.
When you move into the more exotic troubleshooting like this, it becomes more a matter of methodical trial and error guided by instinct, and that’s hard to teach. How can you tell someone to follow a hunch if they never get the hunch in the first place? I’ve worked with a number of people who had great troubleshooting skills, and they sometimes seemed to pull solutions out of thin air. It’s great when it happens, but how do you teach that?