A thoughtful and amusing post from Caveat Lector. It’s not just that librarians can’t code, it’s that they can’t even agree that coding is what (some) librarians ought to be doing.
Librarians can’t code because too many librarians and library schools have their noses so far up in the air about computers that they are neither recruiting coders (which is purest, sheerest madness—why are we not using the exodus of women from comp sci to our advantage?) nor creating them.
Define ‘code’.
*applause*
Well said. My org class was utterly pointless, though the less tech-savvy in the class seemed to find it useful (and disturbingly hard…). I didn’t bother taking cataloging, because I had taught myself the basics by banging around in OCLC for a few days, and based on the comments of people in said cataloging couse, you spent the whole semester memorizing never-used MARC codes and learning how to do copy cataloging on Connexion.
The closest things I got to good computer courses were the knowledge management electives I took–I learned more about the guts of an ILS there than in any of the “library”courses i tackled. While my career path seems to be taking me away from tech services, at least for now, I’m contemplating taking a CS course or two where i work as soon as I wrap up my MLS. Ever-increasing technical features and complexity are the future of Libraries. Hell, they’re the PRESENT of libraries. People who are not prepared to grok this fact and its implications WILL BE left behind.
Dorthea loosely defines the coding she is referring to as “handling digitized information (be it in MARC, XML, an RDBMS, some combination of the above, or something else entirely)” I think in a more general sense is librarians’ willingness to concern themselves with the mastery of the software and hardware based tools that are governing a lot of how many of us do our jobs.
This means things like reading, writing and understanding HTML/CSS/RSS/XML, being able to work with an API, being able to design and work with relational databases, being able to modify modifiable software etc. From my vantage point, at the bare minimum someone in your library needs to be able to understand enough about the technological products you use and the environment that they exist in that you can make sensible purchasing decisions for your library and not just buy off the shelf because you don’t know enough to be a savvy shopper.
The difference between having a lot of technology decisions made in-house by staffers as opposed to externally by consultants, vendors and volunteers can reallly translate into costs both financially and just from a library-autonomy perspective.
I don’t think all librarians need to be coders, but I think one sort of librarian the profession should be turning out — and hiring — in greater numbers is the tech-savvy and tech-enthusiastic librarian.
In many cases, it’s just as important to be able to sit down next to someone who can code and to clearly and unambiguously describe how you might want an existing system to change incrementally from what it is.
A well described use case is worth hundreds of lines of code.
I agree for the most part but I think the HTML/XML is a lot easier to get because its easier to work web design into your every day duties. After using Netflix for the past month and a half what I really think we need is another Andrew Carnegie who’s willing to donate vast sums of money in developing large digital projects that libraries would host and maintain. I’m not asking for someone to send me a book every week with a postage-paid return enevelope but I can’t believe how far behind we are in offering a personal guide/rating tool/reader’s list for books.
As one of those women who fled the programming world, I’m in library school partly so that I never have to write code again. That said, I don’t consider HTML code, and am definitely not scared of technology, I just don’t ever want to spend an entire day looking at code again.
As a former coder who is in library school, and who discovered that, while he thought he was going to school to get away from coding, in fact he wants a job as a librarian coder—it’s not clear what the career path is for such.
“Digital libraries” projects in the academic world seem to be one place where such jobs exist, so, okay. But it’s not the only place librarian coders are needed.
Some libraries seem to have ‘electronic services’ or ‘digital services’ or ‘web services’ librarians (although mainly I can only find Canadian libraries hiring such at the moment). But too many others don’t seem to realize yet that the web page and the OPAC (not to mention the future electronic things people predict for libraries) ARE user services that need librarian types who also know the tech involved, rather than ‘publications’ to be run by the communications department, or ‘systems’ to be run by an IT department that is not particularly focused on the end-user. (In particular, in my opinion the horrible state of most of today’s library catalogs is in part due to this weird divide between the catalogers that don’t particularly understand systems, and the systems people that don’t particularly understand the catalog).
This post made me immediately think along the lines of what you were saying, Jonathan. It seems to me that library organizations are taking more and more of a centralized approach to hiring, where “librarian” is defined as being totally separate from IT or even technological concerns in general. It goes way beyond just tech stuff. Programming (as in library programming/outreach, not computer programming) is often done by non-librarians who are hired to churn out canned programs for us to put on in the library. IT folks are disconnected from librarianship. Library PR departments often seem like they don’t really know what librarians do. I’m not saying that everyone of these departments need to be done by librarians, but only that there needs to be more overlap and communication between these departments. I’m not a code-reader, but I need to understand what that is as much as I can. I’m not a PR person or marketer, but I need to understand that as well, just as those IT folks need to understand what goes on in the daily end-user branches as well. Things are becoming more specialized and separated, to the point where no one even knows how to speak the same language any more.