When I was in library school, I had to learn how to do a reference interview, although I never intended to be a reference librarian. When I was in library school, I had to learn the basics of MARC, although I never intended to be a cataloguer. When I was in library school, I had to learn what a finding aid was and how it was put together, although I never intended to be an archivist. When I was in library school, I had to learn the basics of management and budgeting, although (at the time) I did not think I’d ever end up in library management.
That’s just the reality of a profession with several specializations. You learn the basics of things you’ll never actually do. Nothing wrong with it at all, and no ideology about “the core of the profession” required to justify it. “This is something librarians do” is enough.
When I was in library school, I was not required to learn how to run a server. I was not required to learn how to evaluate software and hardware acquisitions. I was not required to learn about laws relating to library patrons and computers. I was not required to learn about digitization. I was not required to so much as learn how to create a web page, never mind learning to program!
Presumably these aren’t things librarians do. I do them. Presumably I’m not a librarian?
Librarianship has created an immense Somebody Else’s Problem field around computers. Unlike reference work, unlike cataloguing, unlike management, systems is all too often not considered a librarian specialization. It is therefore not taught at a basic level in some library schools, not offered as a clear specialization track, and not recruited for as it needs to be. And it is not often addressed in a systematic fashion by continuing-education programs in librarianship.
This situation is no longer tenable, if indeed it ever was.
A couple of things bring this to the front of my cortex at the moment. One is the deprofessionalization of several librarians in northern Wisconsin. There are quite a few ways to think about this situation. One way I’m thinking about it is in terms of what goes on in library buildings losing its accustomed specializations without adding others. If the library is just a community center and book warehouse, no, I’m sorry, one doesn’t need a master’s degree to manage it. If the master’s-degreed folks can’t manage the same library’s online presence, as the Marathon County library director claims, well…
This situation isn’t just about librarians missing technology skills. A good friend of mine in another Wisconsin library hired a non-MLS for a technology position. She tells me that the clincher wasn’t technology skills—it was attitude, specifically public-service skills. All right, what? What is going on here? One thing may be that the mingled fear and fetishization of technology is breeding tech-savvy librarians who think their skills are a free pass. I’ve got news for you monkeys: nope. Doesn’t work that way. Hasn’t for me, won’t for you, can’t, and shouldn’t. But as long as library schools treat the tech-savvy like lusi naturae, this is how we can expect things to go.
(There’s more to this story, and I have another rant coming, but I need not to give any more specifics, as several someones are involved that I don’t wish to cause harm to.)
Another tidbit that’s come up lately is the report from the New Skills for a Digital Era archivists’ colloquium. Over and over again, the refrain, “it seems unreasonable to expect information professionals to have the skills of a professional programmer or systems administrator” (p. x et seq… et seq… et seq… and if you think I’m kidding about the et seq, read their report yourself).
Why? Why is this unreasonable? It’s not as though a whole lot can get done in a digital era without somebody to run the damn servers. Why isn’t running some damn servers considered a librarian skill?
Because it’s not a library-specific skill? Big whoop. Neither is hiring or event planning or budgeting or project management, and we damned well expect librarians to do those, because libraries rely on them to function. Libraries rely on systems as well. Why can I not add “QED” here and walk away?
Because we can’t teach skills in the two scant years we’ve got? Big whoop. Can’t teach all there is to know about the information landscape either; that’s never stopped us from graduating reference librarians. It’s always been more important to get out there with enough knowledge to get started and enough confidence and flexibility to learn on the job.
Because “professional” skills are too high a bar? Well, sure. The godly sysadmin I work with will be the first to tell you I’m not a professional sysadmin. Anybody who’s seen my code can tell you I’m not a professional programmer. Big whoop. I installed DSpace from scratch (with help) my first day in my first job. I taught DSpace customization less than a year later. If I can do what I do with next to no formal training, so can other people, if they’re not told they can’t and don’t have to anyway. When are we going to stop telling them that? When?
(My students sure as hell didn’t hear that from me, I’ll tell you that much.)
The perverse result of this situation is that our sysadmins are better paid than we are, never mind that IT folks are nibbling away our jobs at the margins. I let slip to the Godly Sysadmin what I’m paid. He was appalled. Why shouldn’t we be in the scrum getting what we’re worth? Or, if you’re a management-type, holding down library costs by replacing expensive IT-specific staff?
It is time and past we stopped drawing lines in the sand around computers. Doing so is unacceptably narrowing our profession and inviting others (including some of our own) to marginalize it and us. As happened in Marathon County. As continues to happen everywhere people wonder whether the library is relevant in the Google age. As continues to happen everywhere friends of mine tell me in IM:
Friend: I just don’t want to go to another place where I’m the token techie and they use me as an excuse to not learn things themselves
Friend: I can’t even imagine what it would be like to actually share ideas about online library services with colleagues
Friend: heaven on earth
There’s a lot of exciting stuff happening around digital tools and digital data. What I personally struggle with is external perception of librarians that simply presumes I am neither interested nor capable of being involved—and a profession-internal perception that This Is Not Librarian Work. Damn it, it’s the work I became a librarian to do. Don’t you tell me it’s not proper work for me, and don’t you tell me I’m not supposed to fit out my students for it.
I don’t do ref-desk shifts, although a few of my close colleagues do. I could, though, with the scaffolding provided me by my training and the local work environment. I know how to do a reference interview. I know how to select and search databases. I know my way around a reference collection (although the one here is admittedly… rather extensive). I wouldn’t be as good at it as somebody whose Real Job it is. Of course I wouldn’t. That’s okay; it’s not my Real Job.
But it’s a damn tiny number of my colleagues who would know where to begin—oh, let’s say putting together a package for DSpace batch import. I have the scaffolding for them, in my library of little Python haxies. There’s nothing conceptually or actually difficult about it. But they can’t, and the sense I get is that damn few of them would even consent to learn. That’s bad. That’s wrong. That should not be—and it will continue to be until the profession naturalizes systems work and the librarians who do it.
Also, just for a second, may I fulminate? Quoth the New Skills report: “Participants made frequent reference to XML as the current standard of choice for a container. A few participants reminded the group that for all its benefits, XML would—like all formats—ultimately become obsolete, and that information professionals must try to think beyond the horizon.” Those few participants? Need to locate a clue, badly. XML is not a good host format because it is futureproof in and of itself. It is a good host format because it is text-based, open and documented, and easily transformable. Given those, you don’t actually have to “think beyond the horizon.” What’s more important is thinking about the now, picking an XML language that actually makes sense given your problem domain and applying that language with skill and intelligence. If you do that, you can rest confident that whatever the horizon brings, you’ll figure something out.
That is, if you’re the type of library professional who sits down in front of computers and figures stuff out. Funny. We don’t seem to have too many of those.
