How My Father Taught Me the Power of Automation

This post is based on the eulogy I gave at my father’s funeral. Although we had a difficult relationship, I learned some extraordinarily valuable life skills from him. I do not think I would be who I am today without that.

Photograph of Dynix Menu via Telnet, taken from Goshen Library catalog, not my home libraryI don’t recall precisely when my local library adopted Dynix.1 I know I was old enough to remember when it happened and that we had a card catalog running alongside it for a while. Based on other life events, I can say I was 8 or younger—first few years of the 90s.

I was fortunate enough to have a family computer (OS/2 4eva) and my own library card, so my father taught me and my little sister how to use this new method of checking on library books which were due and renewing them. He set up an auto-dial program so that when we double-clicked the icon, it would open a Telnet session. We learned to navigate the menus and type in our card numbers and PINs.2

But then my father did something else. As the kind of software engineer who enjoyed a challenge, he wrote a library program.

Let me backpedal a moment to describe the library rituals which shaped our lives and this program. We went to the library every Tuesday night at 7pm. We were allowed to check out a fairly large number of books, and had to be ready to check out by 8:30, so we would get out of the library on time (sorry Miss Ruth, Miss Shirley, Miss Wanda, Adam, Beth, et. al. for all those nights we pushed 8:50 instead).

When we got home, my parents would collect all the date due cards from the back of the books. These went in a little drawer of the otherwise unused writing desk in the living room, along with our library cards. On Tuesday nights around 5pm or 6:30 (just after our 6pm dinner), we would grab the cards and begin the giant book hunt. We couldn’t leave until every due book was found. If finding something proved impossible, we’d take the card to the library and renew it, but this was seen as a failure.

So, when the library allowed us to check our accounts through Telnet, my father had an idea. The program he wrote seemed like magic at first. But as a curious child who used Telnet on her own to renew books, etc., I soon figured out the steps it was doing.

First, the program dialed into telnet. It would login to each person’s library account and acquire a list of books checked out to them. It saved this list in its memory and then login to the next card. After cycling through our family’s four cards, it pulled all the checkouts together sorted by date due, and then sent the whole thing to the printer.

We could execute the program and, in a minute or two, have a printed list of all the books we had checked out. We would run around the house with the list, finding books, crossing them off, and piling them by the front steps. Because the program separated everything due in the next 7 days, we could easily see what had to be found. We’d add anything else we were done with, of course, and then would present our parents with the proof that nobody would get overdue fines. We used that program up until the library shut down its Telnet access.3

As we prepared for my father’s funeral, I thought about how little things like this made me who I am today. I’ve been thinking of this again as I read through old newsletters about Penn State’s homegrown ILS, which it developed through the 80s and 90s.

What I learned from the little programs he built us4 wasn’t the logistics of how to build these—I’m still not sure about how the data grab worked and I am scared of sending things to printers—but that such things could be done. His early attempts to teach me programming were not successful, but he taught me so much by example.

As I said at his funeral, I am so much better about just trying to do things with computers because I learned at an early age that one could. I learned that every repetitive task is composed of steps. I learned that mistakes weren’t the end of the world. I learned that computer programming sometimes involves getting very angry at the computer (or yourself and taking it out on the computer), but that doesn’t mean you should give up. I learned that compatibilities break and you have to fix them. I even learned that sometimes people shut down really good services (like Telnet) and your stuff completely breaks.

While I learned the actual skills and techniques through self-teaching, tutorials, and workshops, the underlying principles that make me willing to try and fail and try again are something I learned much earlier. And I’m grateful for that.


  1. But how cool is it that I know it was Dynix? There’s a spoiler here— I started working for the system when I was 16 and, as a weekly patron, I’m sure that we didn’t do any big migrations between first automation and when I started working.back

  2. At least, I think we had PINs at that point? I honestly don’t recall the timeline clearly enough on whether PINs were involved in Telnet, but the 2019 part of me says “surely?"back

  3. There were times when moving pieces broke, like changes to how our operating system and printer talked to each other. He would repair the program or make temporary fixes like saving it to a document we could view and print manually. This taught me about compatibility and the frustrations of maintaining a working program.back

  4. He also built a GUI program which allowed one to create a shopping list based on item type and then printed items aisle-by-aisle according to the local Pathmark’s layout.back

Photograph of Dynix telnet screen by Skylarstrickland, downloaded from wikimedia commons.

Ruth Kitchin Tillman
Sally W. Kalin Early Career Librarian for Technological Innovations

Card-carrying quilter. Ham. Mennonite. Writer. Worker.