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.
andromeda yelton 
Blogged: after @bohyunkim: talking across boundaries and the meaning of “coder” ≫ http://www.andromedayelton.com/wp/2011/0… #fb
LikeLike
RT @ThatAndromeda: Blogged: after @bohyunkim: talking across boundaries and the meaning of “coder” ≫ http://www.andromedayelton.com/wp/2011/0… #fb
LikeLike
RT @ThatAndromeda: Blogged: after @bohyunkim: talking across boundaries and the meaning of “coder” ≫ http://www.andromedayelton.com/wp/2011/0… #fb
LikeLike
@ThatAndromeda @bohyunkim This is more at the heart of my discontent w/librarians and web org than anything. They’re skills I don’t have.
LikeLike
Thanks for this post! And yes, you are correct I meant mostly #3 by being a coder at the library land. (And even getting to #3 is not easy to everyone.) But seriously, libraries can benefit so much from having more #3 coders and should encourage and support those #3 coder-type wannabe librarians. And I don’t think librarians/amateur coders will care whether they are not real coders or not as their strongest motivation in learning how to code comes from making library resources as easy as possible to access to users. Not that I disrespect discrete math, algorithms, data structure, etc., librarians are fixers of everything in their realm and happy to be practicing tweakers.
LikeLike
You’ve probably seen these but just in case:
http://norvig.com/21-days.html
http://www.catb.org/~esr/faqs/hacker-howto.html
http://edward.oconnor.cx/2009/07/learn-emacs-in-ten-years
LikeLike
One of the commenters on Bohyun’s post linked to the Norvig — which was awesome; if the other two are similarly excellent I shall be very glad to have read them :).
LikeLike
Interesting misunderstanding. When I say coder I usually mean #2 or #3. I would call #4 or #5 programmers. Granted I don’t really talk much to CS and IT folks, so I don’t really know their lingo.
LikeLike
A continuum that I try to advocate which I think keeps the overall problem in focus better is:
consumerproducer.
Coding, however it is defined, is a means to an ends. A lot of conversations on this topic that I’ve seen get caught up in essentially assessing the worth of someone’s technical skill set. In the end, though, the most important thing is whether or not you/your organization tend to operate more as a consumer or as a producer.
There are great engineers who are absolutely incapable of producing anything particularly interesting on their own, and likewise there are people who have kludged together a bunch of awful hacks and made products people use everyday.
There are always ‘techies’ who have an identity based on being excellent consumers, the first to get an iphone or implement a new vendor product. But consuming alone is a dead-end path. Those who produce are the ones who benefit from the act of consumption. Not only do they gain from consumption but they control the direction of the production.
It’s easy to see libraries as consumers, they buy: books, e-journals, ILSs, research tools etc.
It’s also easy to see them as producers: They create spaces, host locally created digital collections, make their own research tools etc.
Of course no one can be a pure producer (we all need to consume somethings to produce; good writers should be great readers) but at the end of the day a better way to assess professional value and progress is asking yourself “How many new things did I create today?”
LikeLike
And I think that’s the second time today you’ve articulated a distinction I was trying to make more clearly than I did :).
I think I would like to see more producers (of locally relevant code) in libraries, in part because that’s good in itself, but even more so because it would make libraries more critical and effective consumers of the tech we run on, and serve people with.
The worth-of-skills thing is so touchy. I tend to feel my own skills are pretty shabby, because the social environment I’m immersed in sets the bar for tech skills so high — and because I know I have neither the time nor the inclination to learn some of the things I would need to know to get to that level, and I know from certain (unenlightened) perspectives that makes me not “worth” it. But I don’t have that inclination in part because those skills have not thus far been needed for the kind of work I do, and I do believe my tech skills are strong enough in the library context to meaningfully produce.
I think I’m thinking that the conversation across boundaries goes both ways. I want software culture to be less judgmental on the whose-skills-are-bigger front and more appreciative of people doing useful work in context, more welcoming to people who want to improve their skills; I want librarians to understand more about the sweep and depth of tech skills that are out there, and what the cutting edge looks like (and how very far from it we can sometimes be).
LikeLike
I have often thought about this topic-not so much focusing on coders within the library, but more how you presented it, with so many ranges of technology abilities. I am finishing up my last semester of my MLS, and am lucky that I have had the opportunity to work in more “techy” library jobs than my peers (currently, I am a Grad Assistant in our Digital User Experience department). However, I wonder if some of the responsibility of making librarians good coders, or at the very least, technologically well rounded, might fall on library schools. My institution offers a dual MLS/MIS, which is wonderful. However, it required a combination of money and time that I simply do not have at this point. The classes for MIS seem more geared towards creating coders for libraries-even maybe #4s or #5 on your list. But for those of us who go straight MLS, the opportunity to take those classes are far more limited. Once you get past the requirements, it is hard to fit in those “other” classes, especially if you are on a track (public librarianship, school librarianship, etc.). I would love to see classes geared towards MLS students that focuses on applying technology in a library setting, while also giving librarians those tools and building blocks to continue learning and expanding technology skills-the capacity to learn technology is probably what I find most important, particularly for my positions.
Anyway, that’s my two cents. I think it’s a critically important topic-especially when I see my friends go off to jobs with the ability to create amazing programs for children, but who are number 1’s in your list.
Great things to think about!
LikeLike
I wouldn’t even begin to use the term “coder” until you have reached #3. The two previous descriptions are “power users,” at best. HTML doesn’t count as coding, unless you are using embedded javascript (at minimum).
I was a corporate programmer for almost a decade, working in teams on very large websites (including major sports teams and large retailers everyone here would recognize by name). We always used “coder” and “programmer” synonymously.
– Jesse
LikeLike