How I ended up learning to code

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.

Eco Warrior

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.

Studying for my Information Management degree we were taught a little HTML, but it was when I became a Systems Librarian in 2011 that I started to get interested again in code and how sofware was written rather than just what it did. I sweated over XSLT files and played with the CSS in our library catalogue. I attended training on Crystal Reports and SQL queries but found the way it was explained simply left me more confused. Over the next couple of years I kept thinking I really should learn to code, but I wasn't sure how, or where to start, and it all seemed very complicated. I did the first couple of activities in a bunch of different free online coding tutorials: Python, Ruby, JavaScript, even Go. It was incredibly frustrating and confusing. Which languages should I learn? In what order? To what extent? It all seemed impossible, yet so necessary. In my more melancholy moments I thought I really needed to create a backup career plan as I saw UK libraries decimated by a simple series of government decisions.

Ask Why

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.

The second golden rule that most people gave me when asked, was that whatever I learned first, it should not be JavaScript. I took on board the first rule - pick a project - but I reject the second. Partially this was because I was lazy and figured I was probably going to make web apps, and that would mean using JavaScript, so I may as well learn it. And I quickly discovered nodejs, which seemed to promise that I could learn one language and use it for both server and client code. As I've learned more, I've come to grudgingly think perhaps the advice was right, but I also surprise myself sometimes with how co