i dream of being possible

My vision for a levelling up tech skills workshop

Okay. Okay. I’m going to do the blog post anyway. :D

So I was talking on twitter how I’d work out a workshop/series/thing for levelling up tech skills for non-coders/programmers/developers/engineers/etc. Basically for librarians or students wanting to level up their tech skills but aren’t necessarily wanting to learn how to code. Or who do want to learn how to code, but are completely green n00bs.


What I want is the tech workshop I desperately needed/wanted when I start at Islandora (or even before). Getting that position was fantastic and was a crash course to level up my tech skills and set me on a new path and really allowed librarianship to become a passion for me, rather than my backup plan for a failed academic career.

So. For me, the key takeaway from such a workshop would be learning to interact with your computer in a different/new way. But also deepening your understanding of how computers operate. Even more critically, beginning to understand how to solve your own tech problems.

The actual skills I’d focus on are probably the commandline (CLI) and git. These two things alone are so important and foundational to the current tech environment (also somewhat helps promote open source, which is definitely a nice tie in with librarian values).

Ideally, for me, I’d like to see these workshops spread over a month or at least more than just one or two days. Time between sessions for people to play around and practise (if they want). Maybe some homework and a place to pose questions in between sessions that other people can answer or for the ‘instructor’ to do so. A forum would be a good one because so much tech support comes from forums anyway and this, again, is a useful part of tech culture that is important to learn but not many seem to teach.

The slowness of it all is important to me because one of the problems I’ve had with the workshops I’ve been too is pace… Not because it moves too fast, but because it means that the instructor (or helpers) spend a lot of time troubleshooting and solving hiccups that prevent the lesson from moving forward. Except… in my experience, learning how to troubleshoot these problems yourself is one of the most important tech skills because almost nothing works perfectly all the time. And understanding the errors that the CLI throws up and learning how to solve problems (ie ‘googling it’ but also understanding which stackedit solution actually applies) is more important than memorizing *nix commands.

So something like this:

  • Week 1: Introduction to CLI
  • Week 2: Working with CLI and git basics
  • Week 3: Using the CLI and git together
  • Week 4: Do a collaborative project with a group.

Yes, an entire week to practice stuff and actually try a collaborative tech project. Using something like github (or gitlab, whatever). Why? Because I expect a lot of things to break. Like, I don’t know what kind of project, but something fairly easy to do and solve. Nothing that involves coding of any significant kind. But does involve working in the CLI and version control (pull requests, etc). But the breaking of stuff and (hopefully) fixing it will hopefully get a lot of the previous skills to be learned… (at least partially).1

Like, for me, the focus wouldn’t really be on making a functional whatever, but about the process. With a focus on problem solving. For my part, one of the things I truly enjoy about doing tech stuff is the problem solving. I enjoy the puzzle-like nature of trying to get things to work. What is engrossing and satisfying for me is the process of doing it, not necessarily the end product. And while this won’t be true for everyone, one of the things I know I had before levelling up my own tech skills is that frustration of not being able to do something or not knowing why something isn’t working as I thought it should but having no recourse to try and fix it.

Tech is often a frustrating thing to get involved with. But I think a decent level up is learning that ‘problems’ have solutions as a why to ameliorate that frustration so that people continue to persist with their explorations and attempts to learn. For me, it is this persistance (and the attendant practise) that has got me from being a complete CLI n00b about 3-4 years ago to the point where I regularly write bash scripts to solve problems and am now contemplating instructing others on how to do the same.

And, no, this isn’t about learning how to code, since tech skills are so much broader than that. I don’t think every librarian needs to learn how to code. But these skills at least open up the door to coding if people want (like writing basic bash scripts!). They’d also open up a lot of other doors since this stuff and the methods can be applied to a lot of different areas. And a deeper/better understanding these machines we rely on everyday is good for anyone, even if they just go home and never open a terminal again.

  1. And the breaking of stuff means a lot of using git as it should be used! And I’ll be honest, git still confuses the hell out of me at times and I often don’t know how to resolve problems, like when it asks you to ‘dif’ stuff and I’m like… O.o wut? How do? But git is a nice safety net where you learn that you can hopelessly break stuff but ‘fix’ it by going back to an earlier version. It can encourage exploration because you don’t have to worry about being perfect.