Roy Tennant’s recent series on assimilating new technology (start here to read it) spurs me to talk about helping library school students do that. My workhorse course, the one I first developed and taught in 2007 that I’ve been teaching ever since, is an introduction to computer-based technologies in libraries called “Digital Tools, Trends, and Debates.” You are all welcome to browse its most recent syllabus.
Most students who take this course are at the office suite–jockey level of computer savvy, though they range from rather less than that (brave souls!) all the way through computer science majors and professional network administrators. Building a course that’s useful to that entire gamut taxes my ingenuity every time I sit down to revise the syllabus.
My 15-week course can’t turn office suite jockeys into programmers and sysadmins; frankly, I’m not convinced an entire LIS program can. Real programmers and sysadmins have entire CS and MIS training programs, after all, never mind all the alphabet soup certifications! Nor can I focus solely on honing the skills of the few programmers and sysadmins who take the course, enjoyable though that would be; they’re the tiny cherry atop a much larger confection.
What the course must do, I decided early on, is turn all my students, at every level of existing knowledge, into confident, self-directed, applied learners of technology-related skills. They must know they’ll have to assimilate and use new technology and work through its societal implications throughout their careers, and, crucially, they must know they can do that. If they don’t leave with that scaffolding, the course fails, no matter what else they learn from it.
Learned helplessness is the chief barrier to self-driven learning I’ve seen among my students, not at all aided by the well-known technology gender gap. My best weapon against learned helplessness is recoverable failure, oddly enough. I tell them openly (since many of them don’t know) that tech experts are made, not born: made by falling down, making messes, and seeking help. Classroom tech snafus become teachable moments, object lessons in troubleshooting and graceful recovery. Next year, I’m planning to add more hands-on metatechnology exercises: writing a useful bug report (and navigating online bug trackers), troubleshooting opaque error messages, hunting for API specifications, looking for and at source code, diagnosing spear-phishing attempts, and so on.
I have learned that emphasizing the library in library technology keeps the course from being too discouragingly geekery-intense for technology novices, while serving the already-expert very well indeed. I refuse to let students out of my class, for example, without a basic nonlawyerly sense of U.S. information law, how the technology world bends it and is bent by it, and how it impacts library programs and services from digitization to e-reserves to ebook procurement to social media use. Similarly, they all need to know the basic parts of an ILS and how add-ins and “discovery layers” are morphing those basic parts out of all recognition, whether they’ll be running ILSes, choosing and paying for them, or simply using them.
I’m still learning how to walk this high-stakes tightrope; sometimes my experiments fail. I taught the basics of regular expressions in fall 2011, but without an advance organizer explaining clearly why, I caused considerably more frustration and less enlightenment than I meant to. I took regexes back out for the latest iteration, but I want to find a way to reinclude them, since even in its failed-experiment state, the exercise helped several project groups convert finding aids to EAD and Project Gutenberg plaintext to EPUB ebooks. Teaching is like technology in at least one crucial way: errors happen, and the only thing to do is sort out what went wrong and patch them up.
The gradual evolution of the final group project bears witness to my try-then-patch approach; I owe Jason Griffey in particular much gratitude for showing me how to improve it. It is split into two parts: the “project plan” student groups produce introduces them to budget, staffing, training, software and hardware selection, scheduling, project management, and other “soft” issues surrounding technology implementation in libraries and archives, while their “technology implementation” makes them come to grips with unfamiliar and nontrivial technology.
I always warn them that they’ll find themselves frustrated, and they nearly always do. Midsemester check-ins occasionally contain politely worded howls of anguish. Now and then I have to hint at workarounds, or help a group think through a roadblock. Most of the time, though, they power around or through whatever the problem is without my help. They learn that frustration isn’t the end, that research leads to recovery from errors and other failures—sometimes, that “breaking things” is fun! (One group intentionally broke built-in hotkeys on a keyboard—not, thankfully, one belonging to the school—so that the hotkeys couldn’t be used to circumvent certain security measures on the patron-destined Linux box they’d built. That’s dedication!)
What I’ve taken to heart in the five-year life of this course is that students excel when I turn them loose and express confidence in them. I’ve almost never had a student group turn in a final project that I thought was lazy or poorly done. More often, they blow my expectations entirely out of the water. I ask them to make a patron-ready Linux installation; they come back with well-thought-through security measures, carefully chosen open source software for well-defined patron needs, and tailored recovery CDs for instant reinstallation. I ask for an Omeka collection and receive works of impressive web design artistry and complaints that they’ve pushed the limits of the software! I’ve gotten mind-bendingly complex EADs, beautiful picture book EPUBs, well-edited digital videos, and fully functional Drupal websites, every last project with meaningful participation from students who started out as office suite jockeys or less.
Best of all is their obvious pride as they demo their work for me and the oft-repeated refrain, “I never thought I could do anything like this!” When they learn they’re capable of much more than they thought, they’ve learned the most important lesson I can teach them.