Bohyun Kim has a great post (and read the comments too), Why not grow coders from the inside of libraries? Interesting questions on why we’re not doing that and how our institutions could better support that sort of development.
The question that came up for me, though, reading through comments, was a question of vocabulary. Her post has attracted comments from both librarians and IT types — which is part of what makes it so worth reading — and I have the impression that these groups are using words like “coder” to mean different things, which is impeding conversation.
From where I stand, there’s a continuum of tech skills that goes something like this:
0. Little or none.
1. Comfortable front-end user: can find stuff in databases, set up a Facebook page or WordPress blog, et cetera.
2. Comfortable back-end user: know their way around a command line and a config file; think that angle brackets and octothorpes are perfectly reasonable things to encounter in a file.
3. Quick-and-dirty hacker: have dabbled in at least one programming language (HTML is not a programming language), can make a few dozen or maybe a few hundred lines of code do something useful, can mess around with an API.
4. Protodeveloper: can usefully contribute small things to large projects.
5. Engineer: can usefully contribute large things to large projects. (Of course there’s a continuum here from junior engineer through guru, too, but that continuum is not important for my purposes.)
I think when we talk about coders in libraryland, we typically mean #3 (sometimes #2, if we find tech intimidating, or #4, if the context is open source, but #3 will usually do). I think when IT or CS people talk about coders, they mean #4 at minimum and often #5. Some of the comments on Bohyun’s post are from computer types who are taking her to task over, e.g., oversimplifying the work that they do, and I think underlying this is a different use of terminology. If I may put some words in her mouth (and please, Bohyun, correct me if I shouldn’t!), when she says “I don’t think that coding is too complicated or too much to learn for any librarian regardless of their background”, I think she’s talking about level 3, and some commenters are upset because they think she just said level 5 is easy.
(I think, of course, they’re both right. Level 3 is straightforward enough as long as you have relatively logical habits of mind and — critically — are not afraid. Level 5, just like high-level proficiency at any complex task, takes years, and you need both hard work and talent to get past its lower end, too.)
I think it would be great if libraries had more of the 5s, but it’s not,on a large scale, realistic. (The starting salary for MIT bachelor’s graduates is $67,270 [pdf]. And your library pays what? I rest my case.) But I think far more widespread level 2 and 3 knowledge, and the occasional 4, is critical. It would empower us to make our libraries work the way we want them to in so many ways (a variety of patron interactions, staff workflows, reporting…). It would empower us to be far more critical consumers, and users, of news about technical advances. And it would empower us to generate far higher-quality demand of our ILS and other technical vendors, by understanding (even if we can’t implement it ourselves) what’s truly hard, innovative, cutting-edge…or easy, sub-baseline, last decade’s technology.
Oh — and it would empower us not to be completely marginalized in the public conversation about information. You know, the ones that the people who understand how to (technologically) manipulate it took over years ago.
