Theology and technology are not always at odds: both work according to presupposed yet flexible laws, and being skilled at either requires creativity instead of mere repetition. Learning each involves success, and necessary failure.
I always liked technology. It interested me as a universe of puzzles, puzzles that – if understood correctly – could result in acts of fascinating creativity. I spent hours teaching myself Photoshop on my own. I learned how to edit and insert files in video games. I taught myself how to create music videos out of movies I liked. It was simply interesting. Another chance to learn something new.
On my own, I had some semblance of skill with certain software and a limited ability to problem solve. I was a wizard at Microsoft Word, but that was only because schoolwork had me constantly figuring out how to use the program. Other than that, I was rather normal (if geeky) as far as technology goes.
Then I got a tech job at Marquette’s Raynor-Memorial Libraries, to help make ends meet during my doctorate. I like teaching, and I understood enough about most library software to instruct patrons in its basic elements. So I enjoyed the job a great deal. It had all kinds of new puzzles every day, and I always had to think on my feet about how to explain something to someone who didn’t know how it worked.
My boss, a laid back guy with a massive knowledge of Macs and other technology, picked up on the way I enjoyed the job. I never said much, but I was good at it and I liked what I was doing. He also picked up on the fact that I had become rather bored. In the end, there are about 10 regular problems every library patron has, and the weird or difficult cases come up every once and a while. Once I figured out the 10 regular problems, I became restless. I learned my boss liked when we experimented with things, so I started taking apart our printers and trying to see how they worked. I was bored. I’d get my homework done at the desk, and then fiddle with a broken printer. I couldn’t sit still.
That Christmas break, I stuck around and helped my boss put together some new Macs that the library acquired. We set up security for patron use, installed apps. He told me what we were doing as we were doing it, and let me try do it, too. I started to work with the Terminal, which is a highly dangerous but effective way of instructing a Mac in various elements of its activity. “If you told the Mac to delete itself,” my boss explained, “it would.” I was rather terrified that he still insisted I learn it. Yet he did. And when I inevitably destroyed several vital files by mistake, he taught me how to fix it.
It was insightful of my boss to figure out that I’d learn anything if someone let me, and that I could retain what I learned and actively build on it by myself. But his real genius was more in the way he taught me what he did. Once he gave me a basic working knowledge, he would deliberately set me with tasks that were slightly too difficult for me. Then I was forced to use what I knew to try and figure out what I didn’t know. It taught me how to problem-solve with Macs, which is just as important as memorized knowledge. I had to creatively apply my knowledge to a new problem, and not simply to an old one. This resulted in a semi-disaster half the time, which my boss was always prepared to address. I was never given enough power to destroy anything irrevocably. We would work to fix my mistakes, and I would not only learn what I should have done, but I also would learn more about how to work backwards through a problem. It taught me to think every which way instead of only one.
Learning is not merely about success. It is related to failure, too. A good teacher understands how to take advantage of failure as much as success. In my case, I became unafraid of failure (with tech, anyway). I’d try to figure out anything, because my experience with failure was not purely negative. I was not yelled at for screwing up. This was something of a revelation to me, as graduate students tend to be born over-achievers who are – in the end – extremely unused to failing at what they do and terrified to fail at it anyway. That’s why they do what the do: because it comes easily. So, here, I learned not to be ashamed of what I didn’t know and what I couldn’t do.
I no longer work at the library in the tech job I had. I’ve got a fellowship now, and my scholarly career dominates my concerns. But I miss the puzzles already, and already have asked if sometimes my current department can loan me out to IT so I can work through a problem again. I also asked the theology department if I can keep working on the websites they’ve got me on. I miss the puzzles. There is something viscerally joyful about seeing a problem, and seeing it fixed. Seeing it fixed. So often in scholarly work, I never see the solution until the end of a long and difficult journey. Even then, it may never see the light of day. I may never get to share it. But getting a friend’s Mac to turn on, or saving their files from destruction: I get to see that, and I get to see their happiness that I did it. It is a simple, human joy. Even though technology is often rather far from human.
I’ll always be grateful for my apprenticeship to my boss, and I don’t want the learning to end. I love figuring out tech puzzles, and would be happy if it could somehow continue. I could, in any case, sell myself as that theology professor who could also fix the server. If I am not hired for my scholarship, I could at least be hired to maintenance the network. I could be allotted a class to teach, and stuffed in the closet with the servers for the rest of my time.