Category Archives: DHums

Library Carpentry in words and numbers: all code, no woodwork

In November I ran a thing called ‘Library Carpentry’. It had nothing to do with woodwork. Rather it was a programme of introductory software skills workshops aimed at librarians and generously funded through my 2015 Software Sustainability Institute Fellowship. This post offers, by way of words and numbers, a summary of Library Carpentry, a wrap-up of what happened during the programme, some initial reflections, and a sense of where we – that is not just I, these things don’t happen in isolation – are going next.

Why we did it

My rationale for Library Carpentry went thus. Librarians play a crucial role in cultivating world-class research. In most disciplinary areas today world-class research relies on the use of software. Established non-profit volunteer organisations such as Software Carpentry offer introductory software skills training with a focus on the needs and requirements of research scientists. Comparable introductory software training programmes with a focus on the needs and requirements of the library professionals do not exist (Data Science for Librarians being a notable exception). This I find curious because research librarians already have substantial expertise working with data and adding software skills to their armoury would seem to be an effective and useful use of professional development resource. And so Library Carpentry aimed to both fill and better understand a skills gap, confident that a proliferation of librarians with software skills can only make world-class research even better.

What we did

So what happened? In it’s initial exploratory run, Library Carpentry took the form of four three-hour introductory sessions held at the City University London Centre for Information Science across consecutive Monday’s in November 2015. We attracted over fifty participants from fourteen institutions in London and its environs, with subsequent expressions of interest both from outside the United Kingdom and from individuals working in comparable professional contexts (such as the archives sector). The numbers tell – to an extent – the story:

  • 1 funder
  • 3 institutions in support (I thank for their generous support my current employer, my former employer, and our hosts)
  • 4 sessions (Full outlines of which are available under a Creative Commons Licence on the project GitHub Page – see wk1, wk2, et cetera)
  • 9 trainers or helpers (I thank in particular Caitlin Moore for her enterprising and level-headed support, particularly when I was attempting to run things, teach, and collect data at the same time!)
  • 10 months of planning
  • 12 hours of learning
  • 14 organisations represented (From both libraries in London and those in the local(ish) area: Sussex, Cambridge, Reading, Leicester)
  • 25 GitHub issues (Including discussions around use cases for the skills learnt and a flurry of queries on potential uses for OpenRefine)
  • 26 cartons of juice
  • 29 packets of crisps, popcorn, and pretzels
  • 59 participants (And more we had to turn away…)
  • 200 rounds of tea and coffee (Short of planned as I made a ordering error on week 4…)
  • 717 #librarycarpentry tweets (And counting!)

How the attendees got on

At the beginning of each session, we asked attendees to self-report their skill level based on the topic at hand. Asked to complete the sentence ‘I relation to the topic this week I know…’ the options each week were ‘Nothing!’ (1), ‘A little!’ (2), ‘Lots!’ (3), and ‘Lots and Lots!’ (4). The reason for doing this was threefold: first, we could get a quick sense of the confidence in the room each week; second, attendees would be able to identify people in and around them who might be able to support them if they got stuck (it was a big group so managing problems well was super important); and third, we could collect a little data.

Week 1’s 2’s 3’s 4’s
One 22 17 2 0
Two 31 10 2 2
Three 27 7 0 0
Four 32 7 0 0
Average No.
28 10.25 1 0.5

Looking at the data a few things stand out: our data collection was patchy, attendees were happier beforehand with concepts (week 1) than specifics (week 2-4), confident people attended to support colleagues, Git scared people off (is the name ‘Git’ a barrier?). What to take from this I’m not sure, but I’m certainly pleased that people who were above the level of an introductory programme agreed (or were persuaded) to come along and help their colleagues and peers to learn some software skills.

At the beginning of week three we undertook some more detailed data collection. Asked to ‘articulate ways in which what we’ve learnt thus far could be used in your daily practice’, participants offered a range of comments that weaved together software skills and their local contexts, some of which I’d hoped to see, some of which I hadn’t anticipated, but all of which speak to the diverse roles that librarians perform in the research landscape. They included:

Getting to know the data part of the challenge. Will prob need to build on knowledge picked up here, but now I know where to start!!!

Possibly combine two csv files (never borrowed + never browsed). Sort in way that removes duplicates (possibly by book barcode number?)

Would need a lot of practice and building up to it… but – batch editing – simple algorithms for doing small but significant change to huge datasets. BUT MOSTLY – talking to the Tech people in clearer, more useful ways

Use grep to compare 2 large spreadsheets (one with 1,000 lines and one with 800,000 lines). Currently do it with excel macros but would be quicker with grep. > 1-2-1 sessions with PGRs or PGs, signposting them to these tools that will make their research easier.

Tidying up large downloads of data from the LMS to track missing items with holds on them.

A full list of responses are at LibCarp-mid-term-feedback.txt

At the close of the forth and final session, we asked participants to tell us the sorts of things they might need to go from learning software skills at Library Carpentry to passing them on to colleagues and peers. Again, some of the responses were expected (time, practice, examples) but others indicate that institutional attitudes to software, professional skills, and data management are potential barriers to embedding and disseminating knowledge. They included:

Not being discouraged to do things myself by/because of colleagues who can do these things by “just” scripting themselves

I need a job at a higher level to give me access to the data so I can play with it eg: analytics in Alma

I need admin access to my computer(!)

Might be able to sell OpenRefine to colleagues but the organisation I work for hates Open Source Software :(

Time, practice, ability to download software to training PCs

A full list of responses are at LibCarp-end-feedback.txt. I plan to follow up with attendees in six months or so to discuss what they’ve managed to pass on and whether their attendance at Library Carpentry as effected change. Fingers crossed!

Where we might go next

In sum, there is lots to reflect on here. This is far from the end of Library Carpentry. I’ve already had enquiries about running subsequent or similar events and money/time/people willing, I’d love to keep this going: perhaps next time with more time spent on regular expressions (because they are great) and a little homework on shell commands (so we can get to the useful stuff quicker). Elsewhere, Belinda Weaver continues to do sterling work among Australia based information professionals to promote the Library Carpentry concept and collect data on needs and requirements. And as a means of sitting back and self-reflecting, I’ve begun writing what will become a co-authored paper describing the institutional and intellectual contexts in which Library Carpentry was conceived, the syllabus used for the initial exploratory programme, the administrative apparatus through which the programme was delivered, the results of small data collection exercises conducted during the programme, what went well, what might need adapting, and future plans. I’m hopeful this will form the basis for a model which the community can iterate, adapt, build upon, and – above all else – get excited about.