This is 'Part 2' of my October GLAM Blog Club posts.
I've been asked by a few librarians about my software programming, how I learned, and what I worked on first. I'm an extremely mediocre dilettante coder. I'm pretty comfortable with that. I'd definitely like to learn more, and I'm open to a future job/career in software development, but at this point I'm pretty happy with what I'm doing at work and where I've gotten to with coding. Nevertheless, I'm sometimes asked how I got to where I am when it comes to coding, and given that it was a much longer and more winding road than it needed to be, I thought it might be useful to explain, so you can avoid my mistakes.
My father was a secondary school teacher, and our neighbour was an electronics enthusiast. As part of some professional development program, Dad procured a BBC Micro PC in the late 1980s. I loved it. I taught myself BASIC and started writing text-based adventure games. In Grade 6 my primary school friend Christopher and I made a game called Eco Warrior and sold it to our high school for $2.00. I can't remember the specifics of the game, or why anyone agreed to pay us anything for it, but that was the last program I wrote for nearly 25 years.
The breakthrough came when I frustratedly 'asked Twitter' which language would be best to start with if I wanted to code for libraries. Several people gave the same answer, which initially seemed frustratingly unhelpful, but turned out to be exactly right: don't choose a language, choose a project. Then learn whatever language that project is written in. It was frustratingly unhelpful because I wasn't really sure I wanted to work an any existing library software project: most of the things I knew about seemed to be very academic-focussed or just mindbendingly confusing. Telling me to find a project just moved the problem from 'which language' to 'which project' - but this advice turned out to be really useful in an unexpected way. What had been holding me back ultimately was that I didn't have a reason to learn to code. Having a goal of 'learn to code' is a bit like having a goal to 'read more books' - it's not helpful if you don't know why you want to do it. The key to learning to code is to have a particular project you want to work on. It could be an existing project that you want to contribute to, like Koha ILS, Blacklight, or Hoodie. But it could just as easily by a really small personal project - Misty De Méo told us at newCardigan's August 2016 Cardi Party that her first projects were to automate some particularly boring archiving tasks. In my case, it was an absurdly over-ambitous thing. I had an idea for a 'zero knowledge' library management system that facilitates library circulation and further reading suggestions whilst protecting reader privacy with client-side encryption. Making a prototype was my stretch goal. It was probably too big a project, but now I now had a goal in mind, which was the key.
Do the Reading
So, that's a kind of rambling explanation of how I got to here with coding. I'm still learning, and there are some things I definitely need to know more about - automated testing, for example. I think all information workers should learn a bit of coding - not because we should all become sofware developers, but because understanding the basics of why software works in particular ways is empowering. If you're wanting to learn a bit of code, I thoroughly recommend Jon Duckett's books, and really any of the O'Reilly introductory books.