Office hours were busy last week. In the space of 1.5 hours, I covered script troubleshooting, managing disk space and quota, conceptualizing how to modify an R script for high-throughput computing, and advising a new workflow for a Psychology project.

All that to say, I have learned a LOT since starting in my role as a facilitator, about a year and 3 months ago. Not only do I have a lot more technical knowledge about research computing, I have a growing picture of the large-scale computing landscape (especially in academia) and the potential for more people like me to inhabit it.

Those pieces of the job have been relatively easy; it’s the more intangible practices and philosophies that have been hard to pin down and really embody in daily work. The more I learn about the technical and logistical details of computing, the more these two “facilitation” principles have become clear to me:

• Push for answers – always find out why
• Don’t just “fix the problem” – think bigger.

The second reminder may seem a bit paradoxical. My job is to help people with their research computing problems – shouldn’t I be fixing things? Well, yes and no. I do want to help people fix their problems. But it’s very easy to walk down a road where I become so focused on fixing the problem at hand that my solution completely disregards the research context, the people involved, or what the best solution might be. Sometimes the best solution is to answer a question the researcher isn’t even asking – in which case, it’s also my job to help the researcher find that question.

That said, the question must be answered! (See the first reminder.) If a user-reported problem or issue is a warning sign on the road, then I have to figure out what it’s saying; not solving the problem is equivalent to ignoring a sign that may tell me about an upcoming missing bridge. Especially when other people are leaning on my expertise, I can’t just shrug my shoulders. I’ve got to dig in and find answers.