There are many thoughts I want to present in this post, but the connections between the thoughts are not fully developed. Therefore, the post comes in several parts.
When I started my first post-MLIS job at Miami University, I was repeatedly told that the position I held – bibliographic systems librarian – was an unusual position in traditional technical services departments. My predecessor (an authority control librarian) essentially automated himself out of the job; he took authority control workflows and made a suite of scripts (mostly macros and server-side scripts) that made his full time job into a part time duty for a support staff member. The role I took on was essentially Technical Services Developer: split between cataloging and programming.
I inherited my predecessor’s scripts, learned the workflows that they covered, and then built new scripts based on the needs of the department. Most of the programming knowledge I have was learned at MU. As the workflows became more complex, more complex and powerful tools were needed. From my predecessor’s Macro Express and Perl scripts came an abundance of AutoIt and PHP scripts. Before I left MU, I started to build scripts using pymarc, digging through the script wizard function of MarcEdit to automate certain database maintenance projects.
My goals were many. Keystrokes saved equal more time to work on other projects. Simple decisions made by the script meant that the staff person can focus their attention on more complex decisions, ones that are not so easily scripted, at least for a novice coder. All of these technological goals needed to operate within the overarching goal of creating and maintaining access of these resources for library users. The scripts I wrote were constructed after analyzing workflows and deliberation about the level of quality that needed to be met in said workflow. We had to strike a balance between entirely system automation and manually editing everything. Once we agreed on a midpoint, a proof of concept scripting phase could begin.
In short, efficiency without sacrificing quality. Saving the time of the user as well as the staff. My purpose was to serve both the public and the staff.
When I asked about the other candidates who applied for my position, a coworker detailed the two types of candidates that made up the majority of the candidate pool: the pure catalogers and the pure systems people. “You were neither, but you had the ability to work with both sides. You were the only one in the pool who got it.”
I walked into the Technical Services department one morning, having been gone the day before to an OhioLINK meeting. I saw one of my coworkers and smiled and said my hellos. Something was off when she didn’t return the greeting. I asked if everything was ok.
She was one of several Technical Services staff to receive layoff notices the day before.
In all, my department was cut almost in half during the first round of layoffs and “early” retirements. The majority of the layoffs and retirements in the libraries came from Technical Services.
The library dean at the time continued to funnel sparse resources into other departments, even with additional rounds of layoffs being planned by the university. Technical Services was left to keep up production with essentially half the staff and a deficit of 60+ years of tacit institutional knowledge.
Second round of retirements and layoffs came soon after the first. Luckily TS was spared; however, it became apparent by the library dean’s actions that my position was seen as a nicety for the department and not a necessity.
I don’t think they ever replaced me when I left in 2011.
Catcode and Libcatcode grew in tandem in the Codecademy’s Code Year push of 2012. After years of being called the odd one in the worlds of Technical Services and #libtech, I saw these efforts as a possible way to get people to see the obvious. Cataloging/metadata work and library coding are not mutually exclusive; in fact, they are secret siblings. For me, this is on the level of saying that grass is green and the sky is blue. It just is.
And the conversation started. A code4lib preconference on the subject. An ALCTS/LITA interest group forming and a preconference at Annual. The first #mashcat conference.
And then conversation stalled.
This isn’t the first time a conversation about cataloging and coding stalled. Many have started on various levels, and yet we always find ourselves having to start from Square One each time we revive the conversation. Why is that?
“Not all catalogers.”
I tweeted that phrase some time ago. It is a problematic phrase to use; for example, it echoes back to “not all men…” to defend against criticism from feminists. But then you have “not all women…” being used as well. I suspect this usage stems from the desire of the speaker to break away from the stereotype being invoked in the conversation. And yet, at the same time, using the phrase in this context reinforces the social trappings that come with the stereotype – “not all $x” denotes that a set within a group does indeed fit the stereotype being discussed and the speaker shares the feeling of disdain for those who fit the stereotype; therefore, reinforcing the majority view of hir group.
Am I that desperate to climb the class structure in librarianship? To reinforce the stereotype by showing that I do not fit it, thus gaining social credibility with my peers?
However, I am no longer a cataloger. I am a systems person who is being hurled into the realm of library middle management.
Perhaps I am experiencing the library equivalent of my inserting an “r” when I say “wash” when I forget that that is not the “proper way” of saying the word while in certain company.
Knowledge is power. Technology is power. Which one has more power, though? I have the knowledge and the technology. I can create the metadata as well as systematically work with it. There are people who have the knowledge and there are people who have the technological skills. However, we see the conversation between the two as more of a one way street.
“You have the knowledge? Here, learn the technological skill!”
Is that what we want from catalogers and metadata people? Are we expected to lean in, to pull ourselves by our bootstraps and code ourselves to relevancy in the current library landscape?
Lean in. I know many who did… only to fall, mostly through no fault of their own.
I watch the new round of conversations start, a #mashcat revived. Every year I feel less lonely; the odd TS person out is joined by other odd people, these hybrids, these “non-traditional” library people. Many folks wear many hats; one thing I heard from folks in the first #mashcat Twitter chat was that they work in both metadata and systems. Great!
And yet… I worry.
While I am excited about the resurrection of #mashcat, we will run into The Wall like the previous conversations did. Folks will hit The Wall hard like I’ve done many times before. There are so many times one can throw themselves against The Wall, but I’m still breathing and able to figure out how to break down The Damned Thing.
I am not sure what The Wall entirely consists of: stereotypes, inertia surrounding change, cynicism brought on by previous conversations. One big component of The Wall, though, is the apathy of librarianship at large about this conversation. They expect the technology to work. They expect the metadata to be there. They don’t care how things are made, like we don’t care how some things that we use in our daily lives are made. As long as it’s there, we’re fine. Status quo achieved for the day.
I don’t know if dragging every library worker kicking and screaming into this conversation is the way to knock down The Wall, but it has become apparent through observations that The Wall cannot be bypassed or knocked down by only a few. We can’t lean on The Wall to knock It down. We need tools: hammers, pickaxes, jackhammers, sledgehammers. We need people to not only provide these tools but to help us to knock The Wall down. It doesn’t do us any good if the same people try to take down The Wall time after time. We need all the help we can get.
A wrecking ball would help as well.
It’s time to have the conversation not be dictated by cowering to stereotypes, to power structures, to class structures.
It’s time for this conversation not be dictated by the actions of a few and being expected to excuse or apologize for these few, reinforcing the status quo every time we do so.
And it’s about time to drag every G*d-damned library manager and administrator by their ears, kicking and screaming, into this conversation.
Rumor is that they have a wrecking ball we can use.
Beautifully said, Becky. I’ve got a thought and a suggestion.
Thought: I think the “apathy” part of why we hit The Wall isn’t pure apathy — part of it is that our progress hits a plateau (as all progress does; progress towards a goal isn’t linear) and we perceive that as diminishing returns. Add that to the stretched-too-thin nature of our jobs (I guess I am our de facto Systems person, as well as head of Tech Services — and in charge of Special Collections/Archives, and digital repository, and serials & e-resources subscriptions) and the constant, grating, ridiculous exhortation to “do more with less” (you CAN NOT do more with less. I can prove it with math) and it’ll steer us straight into The Wall.
Suggestion: instead of “not all $x”, I like to say “many $x don’t”. I know it still splits $x into stereotype-conforming and -nonconforming groups, but it at least avoids the baggage of “not all”. It’s also more of an assertion than a defensive denial. Or it’s just splitting hairs, whatev. 😉