Sometimes sysadmin work can seem relatively thankless–you can be three layers deep in a log file, tracing why a resource-sharing request silently failed at 2am, even while you realize that nobody noticed. That’s not because the service doesn’t matter, but because when infrastructure works, it’s invisible. When it breaks, it’s a crisis. Just as most of us don’t regularly think of the pipes carrying water in and out of home unless something goes awry, digital infrastructure is invisible to most people most of the time. To use a tired phrase, that’s a feature, not a bug.
If you think about it, libraries are infrastructure. Not metaphorically, bu tliterally. And I think the clearest way I’ve come to understand this is by spending my days in front of a terminal.
What infrastructure actually means
In computing, we distinguish between applications (the things users see and interact with) and infrastructure (the systems that make those applications possible). Your researchers search a discovery layer. What they don’t see is the Solr index humming behind it, the nightly API harvest pulling metadata from the ILS, the Python script normalizing MARC records that were last touched in 1987, the Go service brokering NCIP requests between your ILL system and a lending institution three states away.
Libraries have always been infrastructure in this sense. The catalog, the stacks, the loan policies, the interlibrary networks: these are not amenities. They are the connective tissue of scholarship. A researcher who finds the article they need thinks about the idea in the article, not about the OpenURL resolver that routed them there, or the license negotiation that made full-text available, or the systems administrator who spent a Tuesday afternoon debugging why EZproxy was mangling authentication tokens.
That invisibility is the measure of success.
The epistemic CLI
Working at the command line has made me a better thinker about libraries, and I want to try to explain why.
When you interact with a system through a GUI, the interface makes decisions for you about what matters. Buttons appear, options are presented, and the underlying model is hidden beneath a surface designed to feel intuitive. This is not a criticism, since good UX is a genuine achievement. But it shapes how you think about the system. You learn the interface rather than the thing itself.
The CLI inverts this. When you ssh into a server, open a Python REPL, or pipe the output of one tool into another, you are forced to construct a mental model of what the system actually does. You learn that a “request” is a socket connection, that a “user” is an authenticated token, that “saving” is a write to a filesystem that may or may not be the filesystem you think it is.
This maps directly onto library work. Most patrons, and honestly many librarians, interact with the library through its interface: the search box, the catalog record, the request button. But if you want to understand why a discovery system surfaces irrelevant results, or why holdings data is wrong, or why a particular workflow breaks under load, you have to go deeper. You have to read the config, trace the log, and think like a systems person.
Python, Go, and the craft of library automation
One of the things I find most satisfying about this work is that it demands polyglot thinking. In a given week I might write a Python script to batch-process MARC data exported from the ILS, a small Go binary to handle a high-throughput webhook endpoint, and a Bash pipeline to reconcile two CSV exports that should match but don’t.
Each language has a character suited to different problems. Python excels at the messy, humanistic work of data: manipulating bibliographic records, calling REST APIs, transforming one schema into another. It reads almost like prose, which suits the fundamentally textual nature of library metadata. Go rewards you for thinking about systems at a lower level, asking what a process is doing, how much memory it’s using, what happens under concurrent load. Writing Go for library infrastructure forces a kind of rigor that Python gently lets you defer.
This isn’t unlike the distinction between close reading and structural analysis in literary criticism, a parallel I find myself returning to more than I expected when I left the English department.
Why this blog
I spent years as a literature professor before moving into library systems administration. People sometimes treat this as an odd career turn, but I’ve come to think it’s actually coherent: both fields are fundamentally about organizing knowledge and making it findable. The methods differ, and the stakes feel different day-to-day, but the core problem is the same. How do you help someone find what they need?
This blog is where I think through that problem in public. Expect posts about Linux, Python, Go, library systems like Alma and Primo, the occasional digression into the history of cataloging, and probably more than one post where I notice that a Victorian novelist anticipated a modern information architecture problem by about 150 years.
Infrastructure doesn’t get written about enough. This is a small step toward remedying that.