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 comfortable I've become with JavaScript (acknowledging, of course, that I'm still not particularly good at it.) The 'pick a project' advice also conflicted. As I looked around for possibilities, I found Mylar, designed to run on Meteor - a node/JavaScript framework. It seemed to be the perfect technology for my encrypted circulation system. I was sold, and began learning JavaScript, nodejs, and Meteor almost simultaneously. It was everyone's worst nightmare, and yet somehow, it's mostly worked. Now that I've learned more, I somewhat understand why I was advised not to learn JavaScript first. It does have some weird patterns and has probably created some bad habits. But on the other hand, JavaScript is experiencing something of a revival with the emergence of nodejs and the release of ES6, ES7 and ES8, which have introduced some really useful improvements to the language. If I was starting again, I'd probably begin with Python rather than JavaScript, but the original advice stands: choose a project first.
Do the Reading
Something that had tripped me up early is the tendency for online coding tutorials to use mathematical examples and assume a level of familiarity with maths concepts, and to focus on telling you to do something rather than explain how it works. It wasn't that I couldn't work it out, but these examples had no context and aren't particularly interesting for people who aren't maths geeks. I did pretty well in school because generally speaking our schooling system is designed for people who are good at book learning, rather than learning by doing. When trying to learn via online coding tutorials, I found the tables had turned, and I really struggled because I wanted to know why typing that particular command had that particular result. They also reinforce the erroneous idea that one has to understand high level mathematics to be an effective software developer. My friend and fellow librarian Katie Haden helped me out enormously by recommending Jon Duckett's web programming books (you can buy them as a pair) HTML & CSS and JavaScript & jQuery. These books use simple examples and a wonderful design that makes them easy to understand - they both also have really good indexes, which is very helpful - thanks indexers, your work is often under-appreciated! Duckett's books don't go into great detail, but they are fantastic for getting to the point where you're ready for the next resource: whether it's the hugely helpful Mozilla Developer Network documents, Ethan Brown's Learning Javascript - which was particularly helpful for understanding ES6 better - or even Douglas Crockfield's JavaScript: the good parts - though that one is really for once you've had a bit more experience. I've also found both the nodejs docs and the Meteor Guide really useful for nodejs and Meteor respectively. No matter what language or project you're using, Stack Overflow will soon become your friend. Thousands of developers have provided great advice there that can save your hours. Thousands have also provided terrible advice there, but usually it's clear which is which.
Modules
Once I'd chosen a goal (building what became Tinfoil) I had a language - JavaScript - and a framework - Meteor. This actually complicated things, because I worked out how to do things in Meteor by reading the Guide and documentation, but I didn't really know enough JavaScript to understand what I was doing or why things worked. I got things done but later I had to re-learn some concepts - even things as fundamental as callbacks. If I had my time again I'd definitely try to learn as much about 'vanilla' JavaScript before using any frameworks like Meteor. Learning JavaScript primarily as a server-side language by using nodejs, on the other hand, actually really helped. It meant I could start by making small stand-alone scripts, and gradually build more functionality in as I learned more. Being able to build something from scratch in a weekend gave me a sense of achievement, and being able to join these mini projects together like 'modules' gave me a sense of progress. I set myself a challenge to build twelve twitter bots in twelve months and whilst I didn't quite make it to twelve, working on discrete projects like this really helped me to keep learning. And Twitter bots can be really fun, which is absolutely crucuial if you're going to learn (and why I still haven't learned to do SQL queries: I can't find a way to make it not seem tedious, though I know it's something I really should know how to do). Building functionality in separate modules also really helps when troubleshooting problems. The Aus GLAM Blogs app is basically a combination of web app for discovery and search, RSS reader to ingest new posts, and Twitter bot to tweet when new posts are found. These three main functions are mostly independent of each other, and I've simply stitched them together. When I added Pocket integration, this architcture made it quiet easy to add the function without having to change much existing code and risk breaking something.
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.