Top Ten Fears of a Programming Librarian

  1. Being lame.
  2. Worse: Your attendees or presenters feel lame.
  3. Having more people on a panel than in the audience.
  4. Getting stuck in a rut.
  5. Administrators not taking your work seriously.
  6. Lack of buy-in from colleagues.
  7. Dropping the ball (aka Logistics).
  8. Balancing user needs.
  9. Failing to prove your value.
  10. Becoming the nay-sayer (AKA, “We tried that before.”).

While planning a program earlier this year, a familiar fear sat in residence in the back of my mind. What if this turns out to be totally lame? It’s something I find myself thinking often during the planning process, along with repeated worries about marketing and connecting with an audience. Fears #2 and #3 go hand-in-hand, in fact, and are top concerns of mine. We don’t often pay presenters at the library, or if we do, we don’t pay them much, and they contribute a lot of time, energy, and thought to preparing themselves for their time here. Conversely, the audience usually pays nothing to attend, but having given up whatever it was they were doing before coming or could have done if they hadn’t come, I feel we owe them something. So, in the spirit of these perennial fears, I thought I’d create a short list of my top ten fears, which I present as potentially common to all Programming Librarians.

Fear #4 is of course in a totally different category than the first three. It happens more often after a few successes in a row, when the first three fears are blessedly almost absent, and a program has gone so well that it even starts to require less work. For example, we bring therapy dogs to the library each finals period to help students release their frenzied exam preparation stress while petting some friendly canines. The program has been wildly successful, and we’ve done it for long enough that it nearly runs itself. But it starts to make me worry: What’s the next thing? Can we just keep doing this year after year? This goes along with pressure from above, whether overt or direct, eyebrow-raising suspicion or merely positive encouragement to keep moving forward and discovering new ways to engage with our community. Here within an academic environment, there’s also the pressure to make sure that our programming is relevant to the serious mission of the university, which often conflicts with the kinds of events that students enthusiastically respond to (see therapy dogs, above). My former boss once responded to an event I proposed by exclaiming, “Candy! Candy, candy, candy, candy!!!” (translation: Please suggest something to me with some substance!). Sometimes this fear spreads laterally as well. Will people take me seriously? I wonder, as I park my car on Saturday morning and balance coffee and donuts for the overnight hackathon participants, thinking of my colleagues sleeping or enjoying a morning at the Farmer’s Market.

Being a Programming Librarian requires a certain combination of skills, all of which are not typically found in a single human. Most importantly: creativity, enthusiasm, and a willingness to try and fail. But it’s also important to be able to pull many small details together (Did we reserve the room? Who’s picking the speaker up from the airport? Did anyone remember to tell the student paper?), remain calm during chaos, and excel at planning ahead. Unfortunately, those who are naturals in the creativity department often come up short in the planning ahead arena (and, I assume, vice versa, though I have a difficult time understanding the minds of truly organized people). To my relief, I have found that if I can maintain at least one of the three organized person qualities listed above, magic and/or momentum intervenes, and we skate through most catastrophes.

We also worry that in our efforts to meet the needs of some of our population through programs, we’ll take away what others love about the library. For lots of students, that means a place to study. In addition to the prevailing assumption that a library be a quiet place, our students have carved out social norms in our physical spaces over many years. Developing programming is thus a careful balance of experimentation and respect for the existing environment, and in the moment it can be difficult to tell if a single upset patron is a harbinger of a commonly held frustration or a total outlier (see, for example, our single complaint about therapy dogs in three years).

A colleague of mine is new to Programming Librarianship, and we have recently had a few chats about assessment. I struggle with what to say, falling on two points: that numbers or attendance fail to tell the whole story, and to return to your goals (i.e., Why are we doing all of this?) when looking for methods to evaluate the success of your programming. Still, it’s elusive, and measuring the impact of connecting with our community is not as simple as taking a look at student grades after a dose of bibliographic instruction.

Finally, all Programming Librarians live in fear of becoming fossilized. Our field values what’s just around the corner, and no one wants to become the librarian at the end of the conference table, eyes rolling on repeat: We tried that before, and it didn’t work. Of course, avoiding that fate is more difficult than it might seem from the outside; no one wants to be the soccer mom trying out the long boarding trend, either. Striving to keep up with our students and the changing world in a sophisticated and graceful way and without seeming too awkward or out of place is a challenge.

Now that I’ve reached the end of my list, I have a new fear: that you all will think that I (or we) are fueled by paranoia. However, all of this anxious energy has given us balance in the face of the tremendous amount of forward momentum that comes with working with students on an academic calendar. And, like a true addict, I almost welcome the ever-present anxiety, because when a program goes well, there’s nothing that feels better than triumphing over adversity, even if it is all in my head.

Homepage Placement: