The data side: thoughts on tech in the humanities and work

First in a series - beginnings

Note: I am putting a few essays on my substack that wont go on my blog. I eventually want to talk about the database I am now using and the processes to turn cookbooks into data, but I started here, with my origins in “IT” as it were. In other words, this is a personal essay.

I owe my career to a union query.

If you don’t know what that is, it doesn’t matter. If you do know what that is, you’re probably questioning how much of a career I actually have, and you’d be right to do so. But I’ve spent most of my adult life on the bottom rungs of administrative work, someone whose email isn’t worth even putting in the directory. I have never switched jobs without taking a pay cut. And I’ve had more summary job application rejections than I could possibly remember.

The bulk of my working life has been spent in higher education. (I like to say it that way because it makes me sound professional. I don’t have a college degree myself.) Along the way, I’ve accumulated a lot of thoughts and observations about whose work matters, whose time is valued, the quest for job satisfaction, embracing or resisting change, and the role of technology in all of the above.

I call myself an IT person, unless I’m talking to an actual IT person. I probably can’t solve your problem without google. And I may not have heard of that important product or technology that’s been around for 30 years. But I can figure it out eventually. Half of the battle is knowing what is even possible.

I worked for eight years as a data assistant in admissions at an art college. I was liked well enough but was poorly paid and was never considered for advancement. I performed the same mundane processes on a daily, weekly, and annual cycle for years.

Mostly out of boredom, I began using Visual Basic to automate things. I figured out how to build a script that would find the most recent file in a folder, complete the steps of a mail merge, output the documentation, things like that. Tasks not worthy of good pay, yet which most Deans probably couldn’t do themselves.

A database position was created above me, with an unimaginable-to-me 50k salary. I was never considered for it. I once looked over the shoulder of a new hire as she read a “what is a relational database?” page, assigned reading to acclimate to her new job. Our office was volatile, and many hires were short-lived. One of the six or so people who held the position eventually parlayed it into a lucrative career as an Oracle consultant. I was lucky to get a 1% cost of living raise.

I sent out job applications by the dozens. For four years. I occasionally cried from all the rejections. In 2014, when I finally got hired elsewhere, it was my admissions experience that got me the job, not my tech skills, which were all but useless and unproven with no one to vouch for them. I took a pay cut, just as I had when I started at the art college. Back then, I had mistakenly assumed I’d eventually get a raise. This time around, I just wanted out at any cost.

During my time at the art school, I observed as colleagues moaned and griped about change. Upgrades, new software, new processes. “I won’t be like that,” I thought. “I will embrace change.”

But as the years went by, I noticed that again and again, change came down from above with great promises to make our lives easier and save us time and work. The problem is, nobody ever asked us what we actually do.

And so I carved myself out a little space I sometimes call “pink collar IT.” I build automations to perform the repetitive tasks that people like me (mostly women) have to do every day. The stuff that won’t be fixed by some great new product — and may have been necessitated by one. I like to fix problems that administration and IT won’t deign to recognize. Because I value my coworkers’ time and dignity.

Around 2017, the university admissions office I worked in was subjected to yet another “time saving” customer relations management system. Department heads were inexplicably given a say in its selection. We employees, the users, were given the usual vague and exciting promises. “No longer waste time doing ______!” Once we have all that free time, what exactly will we be doing? I wondered.

The end goal is never to make our jobs easier. It’s to make them unnecessary. Luckily, that never works out. Every new system, peddled by the roving used-car salesmen of higher ed tech, inevitably creates the need for some tedious convoluted workaround. The unfulfilled promises of free time and an intuitive workflow will go out the window until the contract is up, leaving an opportunity for the next huckster to sell the same pipe dream all over again.

Because I knew there was a better way, and because the opportunity presented itself, I offered to build an Access database to automate hours of processing work that the new system had created. I set it all up to happen with the push of a button. I’d created tools for myself before, but this was the first thing I made that was widely used by others. I was proud of it, even if it only took five minutes of googling to find the union query that so quickly accomplished what we needed.

I updated my resume with “implemented data pre-processing scripts to interface between application and customer relations systems.” And the next time I started applying to jobs, the rejections were fewer. I even got interviews.

(to be continued)

Next up: what if tedious work is enjoyable? what even is data? why build a research database?