after @bohyunkim: talking across boundaries and the meaning of “coder”

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.

operationalizing your inner rockstar: a response to Bohyun Kim

Over at Library Hat, Bohyun asks — if you can’t get involved much as a library school student, “what can you do to increase your chances of getting a job after the MLS?”

I really resonate with her question. In her case, she couldn’t get involved because she was working full-time on top of her courseload; in my case, childcare limitations kept me from getting involved with student organizations (as I’d really wanted to) or applying for part-time library jobs (all of which paid less than childcare cost; no, thanks), but it comes to the same thing. I don’t know how much my advice is worth since (having graduated in May) I’m still looking for that first professional job, but my mantra was: “a constraint, not an excuse”.

Look, I am not going to go to a prospective employer and say “well, I am SECRETLY awesome, I just couldn’t show it because there were these circumstances that prevented me, but you should hire me over these people who are DEMONSTRABLY awesome”. I mean, I would have to laugh myself out of that job interview. So it was important to me to think — given the constraints I have — what can I do to be demonstrably awesome? Because the alternative is really not an option. The way it’s been working for me:

  • Go beyond the minimum on final projects. If at all possible, produce something which has actual users or a world-visible product. DCKX, my topical index of science content in the webcomic xkcd, was my final project for my subject analysis class — but it was also an excuse to solidify my skills from my databases class; work with real users (science professor beta testers); put something online where it demonstrates my technical competences; and, frankly, do something sexy. OK, it was more work than I had to do and it kind of ate my life, but I was going to have to do some kind of final project anyway, and my other class projects were going to survive if I cut corners.
  • Leverage your strengths. Use the time you do have. In my case, regular weekly commitments were hard, but occasional major time commitments were manageable, as was anything I could do on a flexible schedule after my kid’s bedtime. So I dumped the kid on friends and family for a solid weekend and went to ALA Midwinter 2010 (conveniently next door in Boston). And I did a few presentations at the Simmons tech lab — not too daunting since they drew on my teaching background — but boom, CV entries. And I’m good at writing, so I took an idea I was kind of obsessed with and, in two solid weeks of staying up way past my bedtime and writing and researching and coding like a banshee, wrote a paper that won the LITA/Ex Libris student writing award. Whee! (Then I slept. And did two weeks of overdue homework. I stand by my choice of priorities there.)
  • When you can network, do so, damn the torpedoes, full speed ahead. Janie Hermann wants volunteers for Battledecks? Sure, I’ll throw myself on that grenade. (See above about teaching experience. Teaching middle school is pretty good prep for extemporaneous public speaking…) I signed up for Twitter just before Midwinter so I could join that conversation, and used it like mad at Midwinter and Annual to meet people and find good things to do (both sessions and after-hours); I am flabbergasted at how much it has enriched my life. I spend a few days at conferences forgetting I’m an introvert and just try to be as visible as I can. (Another mantra: “If I can’t be employed, at least I can be famous.” Four mentions in ALDirect so far. And tomorrow, the world.)

Maybe this is not your sort of thing. Maybe you’re not into teaching, and finding time for networking is hard. I get that. The point isn’t the specifics of how I do this (which, heck, for all I know won’t even land me a job) — the point is that we all have ways we are secretly (or not-so-secretly) rock stars, and “a constraint, not an excuse” means that you have to find the ways — within the time and budget and schedule you have — to operationalize that rockstardom so everyone can see it. The constraints might mean you have to be a rock star on a smaller stage than you dream of (or can handle). That’s how it goes (for now). Doesn’t mean I have any intention of sitting in the audience, meekly sipping my drink.

We are all library rock stars

So, how about you? How do you work around constraints to be a rock star?