Niagara Falls

A Twenty Year Journey

I’ve always been an individual of two worlds. One informational; one technical.

When I was younger I just didn’t want to know what something was – I wanted to know why something was the way it was. How did it get to be the way it is? I guess that’s the education side of me. It also is the reason, probably, that I was a history major in college before a professor got a hold of me, saw my aptitude for being information and technology driven, and suggested I move on to grad school and investigate the Library Science program. The rest, no pun intended, is history.

The irony is the technical side of me arose out of necessity. With the exception of a brief period in high school and freshman year of college where I was a waiter, I found myself in two very different jobs for small businesses where I was the sole employee. I was the stock clerk, warehouse manager, and office manager rolled into one. In both situations you had to adapt with phone support, filling orders, and organizing international shipping with customs and border control. Not to mention keeping track of all the paperwork. It wasn’t a bad gig during college, but it left little time for anything else.

What it taught me was the ability to prioritize, organize, compartmentalize, and find the best tool for the job. At both companies the moms and pops that owned them knew just enough how to boot up a computer, type a letter or invoice, and print it out. (1) There wasn’t much more to the skill set, but to be fair computers and software design was a lot different in the early 90s than it is today. All hail Windows 3.11 for Workgroups!

What is noteworthy is during that period I knew what a database was, but I had never actually created one. However, as I looked around, particularly working the warehouse job, and saw thousands of dollars worth of merchandise and only me I knew I had to put something together. So began my first foray into databases. Specifically Microsoft Access 2.0.

Working in that environment I had to learn how to design something knowing I’d be interrupted. Something I could key in data quickly with the knowledge that any shipping service or tractor trailer could knock at the door to pick up or drop off. Or have one of each show up simultaneously. You’d have to print out their specific paperwork, hand them what the need, and then continue with either filling other orders or keying in more data. This was all so that at months end the owners could have their own printouts for the monthly billing cycle for our clients. Even more importantly in order to get my paycheck the clients had to get their bills. Such is the revolving door of money. It never stays in one place for very long.

In order to build that database I had to learn items and concepts I didn’t know. Primary and Foreign Keys. Queries. Creating reports. Data types. I learned these on the fly, and I’m actually glad I don’t have a copy of that database now because I’d be abhorred how it was assembled. It no doubt looked like it was put together by someone who didn’t know what he was doing – which is exactly the case. However, a good database I’ve learned is one that gets the job done. You learn from the mistakes made in every database, and you remember and pay that forward by avoiding the same flaws in the next one you build.

Enter library school and while I learned the fundamentals of library science the first thing I noticed was a MARC record. I’m not a cataloging expert, and like many other librarians it was a class you tolerated because you had to take, but the technical aspects are what held my attention, and now having a more diverse knowledge base I had a better understanding of how everything fits together.

Now, more than twenty years later, it just seems like it was always some logical workflow. That I would end up in a position where I am both a librarian and accidental database person. Or if you prefer, informational and technical. It’s not important just to store data, but to store data for easy retrieval when someone is standing in front of you. That has never changed. It’s always been true in libraries. There have always been reference desks where someone is looking for something, and the librarians assist with that. It’s only the medium that has changed. We’ve gone from cataloged book indexes to card catalogs to MARC and closed OPACs on network systems to putting them on the Internet. The method of retrieving data may change but the questions and retrieval of answers never do. That’s what these twenty plus years have taught me. Whether it’s being able to quickly print out orders to hand to a driver or finding the right materials in the library collection for a student’s research paper data is data. That need will always be there. Maybe more than ever today with the war against disinformation.


(1) They had just purchased Windows ’95, and they had been used to using ProWrite which did not add file extensions, and taught them a terrible habit of adding .DEC for a December invoice. I struggled teaching them what extensions were and why they couldn’t change the .doc to .DEC as a way of invoicing our clients.

Previous Article