Helping the Helper - practical advice for Library Carpentry Helpers

This post originally appeared on the Library Carpentry website

Post by Claire Wallnutt

A couple of months ago my line manager asked if I would be interested in helping out at an upcoming workshop our Library was helping to deliver. The workshop was entitled Library Carpentry. The first thing I asked was “is this to do with the Library Furniture Working Group?” A fair response if you ask me, as we do have a Library Furniture Working Group tasked with the job of creating a functional space (complete with said furniture) for our now empty Microfiche room. He explained it had nothing to do with carpentry actually, but was a software skills workshop aimed at information professionals borne from the Software Carpentry Foundation. Relieved, and with the image of me whittling a new piece of library furniture fading, I agreed to help.


As this was my first time volunteering, it wasn’t a case of just turning up on the day. My line manager helpfully sent on the link to the online lesson plans a couple of weeks in advance. Workshops are split into specific software sessions and each session is broken down into individual lessons with introductions, exercises, and examples throughout. Crucially, these exercises are the same ones attendees would be working through on the day and the questions I would be helping them with, should they have any difficulties. Having this information in advance meant I could familiarize myself with the material beforehand. It was all very new to me but I found the step-by-step information accessible and practical to work through. So far, so good. The particular lessons I would be helping with were Unix Shell, GitHub, and Open Refine. I worked through the lessons about a week in advance of the workshop.

A couple of days before the workshop myself, my line manager (who would be delivering one of the sessions), and another helper met to run through the exercises together. This was invaluable, as any uncertainties we had about particular sections were explained and solved at this stage.

The software: Unix Shell, GitHub, and OpenRefine

Workshops generally cover a data introduction, Unix Shell, GitHub, and OpenRefine. Unix Shell is a command line interface that allows users to efficiently find and manipulate the metadata within their PCs’ directories and files. It does this without opening those files or directories within an application such as Microsoft Word. OpenRefine is a tool that makes cleaning and enhancing metadata relatively quick and easy. The interface resembles those of spreadsheets such as Microsoft Excel or Google Sheets, but offers more features and flexibility in terms of manipulating large data sets. GitHub is collaborative version control tool for those working on group projects, similar to Google Drive or SharePoint.

The Workshop

The workshop took place over the course of a working day and was broken into the four sessions. Dr. James Baker, lecturer in Digital Humanities at the University of Sussex and founder of Library Carpentry, oversaw the workshop. Dr. Baker also delivered the first two sessions of the day: Data Intro and Unix Shell. An introductory session to GitHub followed, delivered by Rod Tatham co-founder of local company Serano. Antony Groves, Learning and Teaching Librarian at the University of Sussex delivered the closing session covering OpenRefine.

There was full attendance on the day - 15 people in total, with three instructors and three helpers. Attendees were a mix of public librarians, university librarians, FE and NHS librarians. “The group sat in pairs and shared access to devices if there was only one per table; there are a number of advantages to this peer programming approach.” In order to have a minimally disruptive method of asking for help, we gave each attendee two different colored post-it notes, one pink and one orange. They stuck the pink post-it note to the front of their laptop devices if they were able to work through an exercise with no problems. If they had difficulties or needed something clarified, they stuck the orange post-it instead. This acted as a prompt to the helpers in order for them to quickly identify and address any difficulties.

Helpers sat at the back of the room during the delivery of the lesson; when the group worked through an exercise, helpers would wander around the room on hand to help when an attendee flagged the orange post-it note.

Surprisingly there were very few instances were helpers were called upon by attendees and, those instances when we were, were for very quick easily corrected issues. The most frequently recurring difficulty during the Unix Shell lesson was incorrect inputting of text command - a simple typo, and once you know what the correct command format is it’s easily corrected. Another issue was attendees keeping up with the pace of the lesson. Naturally, we all work at varying levels of speed, and there were times when a person spent a little longer on an exercise than the majority and then lost their place for the next exercise. The majority of those attending were novices or complete beginners to the software we were exploring and that played a part in their seeking of help.

During the OpenRefine session, there were again only a handful of instances that attendees required help. OpenRefine is an interface that I think information professionals are more familiar or comfortable navigating as it is a little like excel, and not as alien as the Shell interface. For that reason, I think it made our jobs as helpers easier, and our help was needed less often.

Help is at hand

If you are considering volunteering as a helper, you might find the below useful to know in advance of a workshop:

  1. The Library Carpentry and Software Carpentry blogs are full of useful information and blog posts by other volunteers so you know what to expect. I didn’t know about the blogs before the workshop and only discovered them afterward. It definitely would have been helpful to skim through in advance.
  2. Library Carpentry is completely volunteer led. We are all giving up our time to spread knowledge and information. Helpers are not expected to be complete experts in this field, so don’t feel you have to have a solution to every problem.
  3. Be familiar with the lesson material and structure. Lesson plans are available online and all exercises come with solutions. I printed these off in advance so I would have them during the workshop to refer back to, making it much easier to answer any questions on the day. This was also helpful when I was trying to follow along in the session and anticipate what was going to be covered next.
  4. Do a dry run of the exercises in advance on multiple operating systems - Macs, non-Windows, and Windows. Each operating system brings with it its own nuances, such as slightly different commands for example. It was invaluable doing a run through of all the exercises on the different systems, as it not only meant I was familiar with how each setting works, but more importantly familiar with the issues and difficulties they threw up in advance of the session.


I highly recommend volunteering as a helper, especially if you are unfamiliar with Library Carpentry. That might sound ill-advised, but I think it makes perfect sense. The role of helper allowed me to develop a greater understanding and working knowledge of the software taught, than I would have had I attended the workshop as a learner, because I had to prepare and familiarize myself with the lesson materials in advance. As another helper noted: it reinforces your own learning. Volunteering at workshops such as these helps us to keep up-to-date with current practices and advancements in the LIS field. There’s also something very enjoyable and rewarding about being a part of a community of professionals volunteering their free time to the continuing professional development of others. Now I’d imagine that’s a far greater return than the Furniture Working Group…

Many thanks to Dr James Baker Antony Groves and Rod Tatham for delivering such an enlightening and engaging workshop.

Dialogue & Discussion

Comments must follow our Code of Conduct.

Edit this page on Github