Warning: fopen(/home/.lasher/yarinare/cavlec.yarinareth.net/wp-content/cache/) [function.fopen]: failed to open stream: Is a directory in /home/.lasher/yarinare/cavlec.yarinareth.net/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 96
Caveat Lector » Learning how to learn

Dies Mercurii, 10 Augusti 2005

Learning how to learn

Via the Carnival of the Infosciences, I came across this LITAblog post by Eric Lease Morgan on what a systems librarian needs to know.

I respect Mr. Morgan a great deal (I defy anyone to find a systems librarian who doesn’t), and I disagree with almost every word he said after the first two paragraphs of his response.

Sure, everything he mentioned is a good skill. (I can manage four out of five myself, and I’d love to play with swish-e sometime.) But I could come up with a completely different and darn near equally valid list. For the sake of argument: XHTML, CSS, hardware/software installation and troubleshooting, Unix, basic networking. And neither of us has gone near ILSes, metasearch, repository software, or other library-specific tech, you’ll notice.

These lists are pointless (mine emphatically included!). They’re outdated as soon as they appear. They tempt people to think that if they take a few tech classes and learn a few incantations, they are magically anointed systems librarians. It just doesn’t work that way. Systems librarians don’t all do the same work, and there’s a lot of systems work in the average library. Moreover, the work changes, constantly and from the foundations up. Doesn’t matter what you learn today; you’ll be doing something else next week. Without explicit training, probably.

So what do I think makes a good systems librarian? Acceptance of the unknown (also known as “willingness to experiment”), ability to learn while doing, patient and systematic problem-solving technique, and high frustration tolerance. (You can cuss when you’re frustrated. I do. You just can’t give up, that’s all.)

If you freeze up or cower faced with an unfamiliar computer, program, or program error, you’d just better get over it or find another line of work. Harsh, I know, but realistic. You need to be able to step back, reconstruct what happened and what’s happening, and think just enough like a computer to cope.

Stuff gets implemented in libraries before it’s ready, just like everywhere else. Documentation? Ha. Training? Double ha. Systems librarians sigh and dive in. This means sometimes all you can do is follow somebody else’s none-too-clear instructions, without understanding what’s going on—at first. As you do whatever it is you’re doing, you gradually build a mental model of it. Six months later, you dominate it and make it dance to your tune. Again, if this process sounds like a foreign language, that’s a problem for anyone wanting to be a systems librarian.

Computers are fragile, hardware and software. (Hardware less so than previously; software vastly more so.) Stuff breaks in the weirdest ways you can imagine. The systems librarian’s job is to find a way through or around the problem, using whatever tools and resources are to hand (including, obviously, human resources, by which I do not mean the hiring and payroll people).

All of this can be astoundingly frustrating. Unbelievably. A well-developed curiosity helps. So does sheer bloodyminded determination to win over the damnable machines. Use the coping mechanism of your choice, but make sure you have one. (Mind-altering substances not recommended.)

I say all this with a knowing grin, because it’s exactly what I’m going through now. I know lots more about DSpace, Java, OSX, and Apache/Tomcat/JBoss than I did a month ago. I have lots more to learn. How will I learn it? Well, the Java I’m going to give myself a head start on with a class. The rest I’ll learn the way I learned SGML, CSS, Python, and almost all the other miscellaneous computer stuff I know. I’ll beat things with rocks until they work.

You can test yourself for these attributes. Just do something substantive that’s wholly unfamiliar to you on a computer. Install Apache. Install Linux. Build a home network (bonus points if it’s wireless or multi-OS). Build an XHTML/CSS layout. You can have a lifeline, and all the online or print documentation you can scare up, but no fair somebody looking over your shoulder every minute telling you what to type. You have to suffer through it pretty much on your own.

If you can do that? You’re a promising candidate. Now go learn what’s on Eric’s list. Or on mine. Or better yet, make your own list. And good luck to you.

atmotorola v3c ringtoneshigh pitch ringtone