Uncertainty will never be zero
Patrons could be forgiven for thinking that the librarian’s mantra is “Didn’t learn that in library school!” Someone else can do the off-the-cuff Google text-mining on that phrase, but trust the Loon, it’s everywhere.
As the Loon has mentioned before, the antistrophe to that strophe is invariably “library schools oughta teach that course!” Now, chances are rather decent that they do but the choregos didn’t take it, which is the inevitable concomitant of permitting students to exercise free will in program selection. As for “library schools oughta require that course!” the Loon has had her innings on that one, and has seen no reason to change her opinion the merest iota.
What the Loon has noticed in the last few weary “didn’t learn that!” go-rounds is first, that complainers rarely consider the teaching logistics involved in their complaints. Taking technology as an easy example, a common complaint is not having learnt about the specific Integrated Library System or institutional-repository package or digital-library package (or whatever) in use at the complainer’s workplace.
Let us consider the ILS. There are two major open-source ILSes (Koha and Evergreen), and let us say at least four major proprietary ones (which would not cover every library by any means, but seems a reasonable 80/20 point). Who exactly is going to install, maintain, populate, communicate with vendors about, and pay for six ILSes? (For added bogglement, add discovery layers into the equation.) The library school the Loon works at does not even have a dedicated systems administrator! Moreover, since library schools are not gifted in prophecy, there is no way to choose which ILSes to focus on in order to cover all students’ eventual workplaces, so all ILSes would have to be taught. With how much time (for reference, a typical semester is fourteen to sixteen weeks long) spent on each? And is the time spent on the five ILSes a given graduate is not working with therefore wholly wasted?
If you gather that this specific variety of thoughtless complaint stirs up the Loon’s natural irascibility, you would be right. When she is feeling charitable, however, she asks herself about the anxieties and unfulfilled expectations underlying the complaint, as well as the larger “didn’t learn that!” phenomenon. Phrasing them (in the best pop-psych fashion) as “I (don’t) want” statements, they might look something like this:
- I want to feel expert, professional, an insider; I don’t want to feel like a fraud.
- I don’t want to be unpleasantly surprised.
- I don’t want ever to feel at a loss about what to do in a work situation.
- I want everything I studied in library school to be immediately and indefinitely relevant to the work I do.
- I want to have made the best possible choices about how I spent my time in library school.
The first “I want” above, the Loon suspects, is the most pressing and deeply-felt for many professionals, especially new professionals. Given the gender balance of librarianship and its current technology demands, the Loon can’t help suspecting Impostor Syndrome as a common, powerful, damaging force.
That aside, though, what strikes the Loon about all the above statements is that in practice they are unachievable, every single one of them. In no universe the Loon can imagine could she guarantee that her students wouldn’t be surprised, wouldn’t have to learn anything else, wouldn’t have to suffer through topics (or even whole classes) that don’t mesh with their eventual careers (remember, the Loon is not an oracle and cannot predict who will employ her students!), wouldn’t have made unfortunate course choices.
Moreover, what a boring work world, where two short years teach all a professional will ever need to learn! Steady-staters may well want that world, but the Loon surely wouldn’t wish it on the larger populace.
Uncertainty will never be zero. There will always be more to learn. Some information is meant for others. Honest folk admit to themselves that anyone can feel like a fraud, and that feeling does not necessarily reflect reality.
Library school can’t fix that.
Definitely agree. As a new librarian, I think that basic “what is an ILS and what can it do, generally” questions are all that needs to be covered in library school. Other questions can and should be approached through work experience- during library school, if possible.
To continue to apply the ILS example, when I got my first job I ended up having to learn an outdated ILS that hasn’t been updated in years- and isn’t one of the Big 4ish anyway. Would learning Koha or Voyager in library school have helped me? Probably not all that much. You never know what you’ll end up with when you get into the workforce. Besides, the attitude that “the ILS is so important that it will be taught in a Masters’ program” is limiting! I want to feel like should the ILS ever “go away” I won’t be so attached to it that I hold us back. And I’d happily apply that to the discovery system, or whatever else is the new tech or product of the moment.
Speaking again to your specific example: I’m a cataloger with some systems-ish responsibilities, and I think teaching specific ILSs would be madness. And it’s not just ILSs — you mention discovery layers (each of which potentially comes with separately licensed “web-scale” discovery options), link resolvers, e-resource management systems, federated search tools (yes, some people still use them) — and all of these systems need to work together, which is a tall order even if all of the products are from the same vendor (speaking from long experience). Even if it were possible to license/install a selection of ILSs in library schools for teaching purposes, learning the ILS in isolation would not be especially helpful for jobs in the current environment.
Teaching students about each of these kinds of systems in a more abstract way (what each one does, and what kinds of challenges librarians face in making them work together) in a more abstract way might be useful. Learning about web architecture in general is certainly useful. Understanding XML and the challenges of metadata interoperability would be very useful for certain kinds of jobs. But too much specificity is rarely helpful. The most professionally useful courses I had in library school (which was now 10 years ago for me) were the ones that focused on big-picture issues and abstract principles. These taught me ways of thinking and analysis that can be applied to whatever specific systems/products/metadata standards are in vogue at the moment.
Unfortunately, I think far too often we prefer candidates with specific system experience when we’d be better served trying to hire candidates with the best set of relevant analytical skills. It’s hard to identify those people, however, when you have is a stack of 50 resumes and cover letters that must be winnowed down quickly and ruthlessly.
While in library school, I took as many classes on “automation” as possible, because I wanted to be a reference librarian and knew that if I learned how the damned things worked I could use them better. Every single system I learned as a text based, command driven system was replaced within 2 years by beautiful (ahem!) web interfaces with nary a “AU:” or “TI:” to be seen. Were all those classes a waste of my time, because they didn’t teach me what I needed to use (even though it didn’t exist when I was learning)? No! I learned how they worked and so could extrapolate to the new systems. So I know why I can’t search for a publisher name in my OPAC; I rejoice that I can search over the entire span of years of an index, not merely the 1-5 years of the currently loaded CDs, etc. And full text searching! Ye gods! Bring on the new!
I took the ILSes class in library school, because it was so obviously useful. And we used one of the open-source ILSes, because duh, right? (Actually, two — we had brief exposure to a second.) And I felt this was a good way to expose me to the concepts of ILSes, in a way that I would be able to generalize to other interfaces.
Problem: job ads rarely say “experience with ILSes”. They say “experience with [insert name of specific ILS here]”. *headdesk*