Systems librarian tool kit
Congrats on getting the new job as a systems librarian or library support specialist. These lesser known roles in libraries are increasingly important, as we are responsible for keeping our integrated library systems (ILS) moving. Here are some tools I have found useful, in no particular order. If you find an obvious tool I missed, which is likely, please share it with me Craig Boman.
Password Manager: you are going to have a lot of passwords to vital stuff. You should most definitely have a tool to generate and manage secure and unique passwords. Your security admins will love you.
Text Editor: you will be working closely with lots of different file types and you should have a tool which can read most any file formats. I vacillate between Notepad++ and Atom, but there are loads of options. If you need to read giant text files Vim is great.
Relational Database Administration Tool: you should not only be interacting with your ILS database with the vendor’s desktop application. Tools like PgAdmin v.3 will help you get directly to the database tables you need. Avoid PgAdmin v.4, its rubbish. Querying databases is a skill. Expect to work through the learning curve. Try finding some sample queries, to help get you started.
Desktop Automation: do not be content with manual repetitive tasks. When you prepare to load that report for the second time this week, try to think of areas in your daily work where you can automate all those mouse clicks. I would recommend AutoIT and AutoHotKey, and increasingly Pywinauto if you like a challenge. If you are on linux, you should already know about cron jobs. Not sure about automation for Macs.
Streaming Music Player: duh! Needs no explanation.
Documentation: most vendors have great documentation. These will be an invaluable tool for your growth.
Screen Recordering: this will come in handy when you are failing to explain how to do something. Screen-cast-o-matic can load directly to Youtube. Certainly Jing has some similar features.
MarcEdit: made by Terry Reese, this tool will be increasingly useful when you need to edit large batches of bibliographic records.
Github: librarians who occasionally code are not the best at working collaboratively across libraries to develop code outside of their silos. I would encourage all librarians to view local coding projects as being useful for the library industry as a whole. And by browsing repos, often you will find some one who already built what you need.
MOOCs: you aren’t expected to know everything, but you are expected to know how to get the job done. Often getting the job done means buying a Udemy or Udacity coding course. Learning is not a goal, it’s a process of lifelong growth.
Showing up: as you are troubleshooting ILS problems for your staff and library users, you will often find how they explained it over the phone did not get to the heart of their actual problem. Showing up in person to troubleshoot has been a huge time-saver, to see what’s really going on. As the saying goes: Trust, but verify.
Community: there are literally thousands of people out there who are doing your job, or something that looks like it. Keep in touch with everyone by going to conferences or find a Slack. I would recommend the Code4lib Conference and Code4lib Slack as a place to really dive in, even if you don’t think you are a coder (yet). There are lots of options for ILS community. Don’t live in a silo. Silos suck.
Data: the best way to make design decisions, is through data-informed decisions. The best time to plant a tree was twenty years ago; the best time to gather data was before you needed it. Gather data even if you don’t know what you will use it for yet. But be careful to keep in mind patron privacy (hint: privacy is paramount, even if you don’t have anything to hide). It is even in our ALA Code of Ethics.
Flexibility: The only constant in life is change.
VPN: you are going to be testing off campus access on occasion. Try a freemium VPN like TunnelBear, to see if VPNs are for you.
