New librarians, or librarians still in school, often ask me how they can get a job like mine. I think this is probably a question all librarians get, but mine comes with an extra question: “should I learn to code?”
My answer to this has always been something along the lines of: “Well, no.” I know many people would say the opposite.
I don’t think code is important to my job because I do not write code. I shouldn’t write code, actually…I have colleagues who are responsible for any code that might come near me. Code is not my territory. So no: you don’t need to code to be a librarian who works in tech. Content management systems handle the HTML. You won’t be the one messing around with CSS, probably. If you work in larger library, in any case. Librarians are usually not the best qualified people to tweak stylesheets or write software. Those things are halmarks of a whole other profession, actually. If you learned a tiny bit of code, the truth is, you’d be a terrible coder anyway.
But still: there’s something there. Lots of folks in my shoes would say the opposite: yes! Dear god, yes, please learn to code! I genuinely have no idea who’s right and who’s wrong here.
My feeling on this is that librarians who picked up code learned a lot by doing so, and think that others will learn the same things if they too pick up code. And that might be true. But in the end, the code isn’t the thing. The code is a catalyst for the thing that’s really valuable for a librarian. Somehow the process of learning even a tiny bit of code might be the easiest way to understand the basics of how the internet works, and that understanding helps you to ask better questions, form better plans, make more realistic requests, and integrate your services and your collection more thoughtfully into the wider digital world. But the code isn’t what does it: the code is just the catalyst. Right?
My fear, I suppose, is that in this drive to learn code, someone will actually just focus on the code and will miss the catalytic moment. Because we’re not being very clear about what we actually need you to learn. We haven’t specified. I’m not even sure I know how to articulate it all even now. We need you to understand what’s possible, and what’s impossible. How data travels and is taken up into new places. You need to know that it’s not magic, it’s just content drawn out and drawn upon. You need to really understand what “database-driven” means, and be able to apply that knowledge. You will probably get that from learning some code. But I think it might be more efficient to be clear about the kinds of lessons we need you to learn from it.
And I suspect it’s possible to learn those things without code specifically. I think learning by doing, by figuring things out, is probably going to work for most people, but what are you figuring out? It’s a set of problem-solving skills, it’s not a skill at coding, necessarily. And some people get that understanding it other ways altogether. I know several outstanding library leaders who never learned code at all, but can make rational, thoughtful decisions around tech. I think they just listen to the people they hire, to be honest. They trust the people who understand it better than they do.
But I suspect code will get the majority of folks where they need to be. I suspect that’s true. But it might be the hard way. I’m not sure. Either way, it’s true they need to get there, one way or another.
Maybe I’ve been giving bad advice all along. Or good advice. I have no idea.