Librarians and programming revisited

Recently, Peter Murray wrote on The Security Implications of Teaching Librarians to Program, and I agree with both the potential problems and his solutions. I’d add that I would never want to do any programming on a server that contained student data (we are lucky to have several of our own spaces) for obvious reasons. I wouldn’t recommend it for even experienced programmers if they can help it, especially when working in the digital humanities where we are always trying new things. Luckily, server space is cheap, and I think it would be well worth $100 a year to get some commercial web space for a librarian who wanted to try building something. Alternately, the library could try and get an old server to use as a testing space for budding coders. The same could be said for DH students who want to try their hand at building a project of their own.

Peter’s post got me reading my old post on  Why every Library Science student should learn programming from 2008, which is still one of my most popular. I thought it might be a nice time to reflect on whether I still think it’s true (spoiler alert: I do.)

Many of my original reasons hold true (especially being able to migrate data formats oneself) but some of them are a little… optimistic, shall we say. I don’t think that librarians should be handling the ILS backend necessarily, and I think libraries should be hiring trained programmers for much of this stuff when they can — not that there will never be any overlap. I still think programming should be written into the library school curriculum, though.

In the last 4 years, I have served on a lot of project teams with a lot of different types of people with a lot of different digital projects. Some of my favorite people to work with are the semi programmers, the ones that know enough to have done some initial exploring, but also know that to build something ready for prime time, it’s best to call in help. These people know how hard programming is, and so they tend not to be the ones who expect a turnaround time of a few hours for complicated requests. They also tend to be the ones who are best at explaining what it is they want: not only the ideal version, but the good enough version (we usually end up somewhere in the middle.)

This is one of the reasons I think librarians should take a programming class: there’s nothing like beating your head against that wall to make you realize how complex this stuff is. Add to that that it increases the chance the librarian will be able to explain things when he or she needs help: what exactly went wrong, what they think might be the problem.

The other reason I still agree with past me has little to do with whether the librarian will actually use programming in their job. I have been approached by several people over the last few years who ask me, hopefully, about library school. One of the common threads I see is some of them want a place where they can stay away from technology. Some (still!) see libraries as a last refuge for luddites. It’s not that luddites can’t have a place in libraries, but I think those places are few and getting rarer. Requiring a programming class is like requiring cataloging even of those who are positive they’ll never be catalogers: it’s a minimum standard to reach, a proof that you’re willing to at least try other ways of thinking about data and information.

To be honest, I’d like to see library school in general get harder. I would have liked it to be harder. I have a friend in library school now who is shocked and dismayed at how easy it is. For the brightest, at least in some programs, there’s very little challenge and few opportunities for growth. Programming is challenging. It forces one to see computers, and information, in a new way. Whether or not one ends up using this for a career, it shifts how one thinks about things. That, to me, is the benefit.