by Laura Wrubel, Daniel Kerchner, Justin Littman

Inception

GW Libraries piloted a programming and software development consultation service for the university community in Spring 2016. The consulting service originated with the Scholarly Technology Group (STG) at GW Libraries, a unit composed of librarians and staff with technical expertise and responsibilities for supporting academic work at the University. The idea had been developing within STG for a number of years, prompted by faculty and students who would find their way to STG with technical questions. It gathered further motivation by members of STG listening to the needs of researchers at events like ThatCamp or the annual digital humanities showcase hosted by GW Libraries. We sensed there was a gap in campus support for researchers and students, particularly in the social sciences and humanities, who wanted to get started with projects that require digital tools, and that we in the library were well-situated and prepared to fill that gap.

In September 2015 we began preparing a project proposal — a short document describing the goals, scope, benefits, risks, and implementation details. The project proposal incorporated feedback from GW reference librarians, select faculty, and GW Libraries’ senior leadership. In addition, members of NYU’s Digital Scholarship Services were consulted for guidance. We also attempted to determine any overlap with services offered by other parts of the University, and did not identify any. We were given approval to start offering the service in the Spring 2016 semester. Based on the success of the pilot and with support from senior leadership, we are permanently adding software development consultations to the growing list of services offered by GW Libraries.

Goals, Scope and Risks

The primary goal of the consulting service is to support academic or scholarly inquiry which requires coding. This goal is intended to be reasonably broad in scope and audience, which includes faculty, students, staff, and researchers. Some of the areas that are in scope include:

• Guidance on coding/software development/scripting/programming, including:
  • Recommending a learning path and coding tutorials
  • Advice on starting a new coding project
  • Code review/debugging
  • Tools selection
• Assistance with:
  • Working with data markup/encoding (e.g., XML, JSON, CSV, RDF)
  • Retrieving data from websites/APIs
  • Data cleansing/manipulation
  • Databases (e.g., table design, querying, optimizing, loading)
  • Fulltext searching
  • Online exhibits
  • Data visualization

The consulting service is not without limits. In particular, there were a number of activities that we specifically placed out of scope:

• Computer Science (or similar) assignments
• Writing entire programs or doing all work for researchers
• Tutoring
• Filling function of TA for a class

In addition to supporting STG’s mission of academic work, our secondary goal was to increase interaction between STG staff and the GW community in support of GW Libraries’ strategic objective of being “the nexus for cross-disciplinary collaboration on campus.” In that vein, we thought that this interaction might provide insight into topics for future workshops to be led by team members.

During the project proposal phase, we identified a number of risks. Foremost among these was that the consulting service would excessively consume library staff time, especially if a consultation continued beyond the initial meeting. Further, there was a concern that library staff would be in the position of having to regularly deny researcher requests either because they were out of scope or exceeded the limited resources.

Implementation

For the pilot, a total of two hours of consultations were made available per week in half hour meetings, using the Libraries’ existing Research Calendar. GW faculty and students could select an appointment from this calendar, which is also used to schedule reference, GIS, statistics, and similar appointments. The appointment form requests the course name, topic/research question, and resources already consulted. Members of the GW community were also welcome to email us if the scheduled time slots were not convenient or if a remote (WebEx) consultation was preferable.

The consultation service is staffed primarily by the three authors, who work as software development librarians. Though we have fairly wide-ranging technical expertise, we identified gaps in our skills and connected with others in the Libraries, including our web developer and a digital operations manager with R skills. When a staff member received an appointment request, she made sure the topic for the consultation was within scope. Depending on the topic, she might contact the requester by email to clarify the need, conduct some research in preparation, or find a different staff member with relevant expertise. In several cases, the original staff member would sit in as a learning opportunity. We held the consultation meetings in the same offices on the Gelman Library’s main floor used for other research appointments. These rooms were equipped with external monitors, which proved useful for collaboration.

For tracking purposes, a ticket was created in our helpdesk system for each appointment. The staff member would add notes on the appointment and update based on any follow-up. An estimate was kept on how long each consultation took. The ticket was used solely for internal recordkeeping and not for interacting with the student or faculty member. The helpdesk system was not the ideal fit for this task, but good enough for our limited use.

A key part of the implementation was publicity of the consulting service. We were fortunate to have the assistance of Robin Delaloye, GW Libraries’ Director of Communications and Research, who has deep experience in marketing the Libraries’ services to the GW community. Some of the mechanisms used to publicize the service include:

• Digital signage within the Libraries
• Announcements via Twitter
• Announcements in the Libraries’ poster newsletter (“Gelman Exposed”)
• Displays, flyers, and/or talks at relevant campus events
• Web page providing additional details on the service
• Briefing to reference and user services staff

In addition, we received some secondary publicity including an article in the student newspaper and a blurb in the Office of the Vice President for Research’s email newsletter. While we don’t have firm evidence, our intuition is that the digital signage provided the most exposure, as several students referenced the digital signage as the way they learned of the service.

From a marketing standpoint, our biggest challenge was what to call the service. The merits of the terms “coding,” “programming,” and “software development” were considered before we settled on “programming and software development” consultation service.

Providing quality service

While we had experience helping the GW community with software and technical projects on an ad hoc basis in the past, we had some anxiety about this new service. Would we have enough knowledge about the topics to be helpful? Would we be able to meet the expectations of students and faculty consulting with us? As we began meeting with students and faculty, we found these fears largely unfounded.

The appointment request process helped address our concern about being prepared to help individuals. It provided a starting point for a conversation to understand the possible need, allowed us to identify tools and resources in advance, and to brush up on a particular tool if needed. This pre-meeting conversation also helped ensure the consultee could come prepared to get the most out of the meeting. For example, we might recommend they bring a laptop and install Anaconda in order to have an easy-to-use environment for working with Python and Jupyter notebooks.

Similar to our colleagues’ reference interviews, consultations involved a conversation to explore the consultee’s need and seek an understanding of the best approach. Sometimes the consultee requested help with a particular tool in her appointment request, but in conversation, it became clear a different approach would be better suited to reach her goal. For example, one student requested help scraping several web pages, but we found that the website provided an API. We were able to work with the student to get API keys and use Python to request data and parse the response into a CSV file.

One of our concerns in embarking on this pilot was whether we had all of the knowledge and background to easily answer questions about a wide range of programming topics. We had strategies for coming to the consultation prepared to be helpful — from background research on the topic to polling colleagues and bringing them into the consultation. But what about during the course of the meeting? We found that our gaps in knowledge or memory turned out to be useful opportunities to model how to answer programming questions. We could show consultees that most code doesn’t work as planned at first, and debugging and checking reference materials is a typical practice for all software developers.

Outcome and lessons learned

We provided 13 software development consults over the course of the semester. It took a good month before our first appointment, perhaps due to the ramp-up on the marketing and/or the tempo of the semester. Activity was steady through the rest of the semester, with appointments tapering off at the end and the summer continuing with few appointments. There were typically 1-2 appointments per week. Each appointment took, on average, 1.8 hours of staff time, with the greatest being 4 hours. Overall, we were pleased with both the number of appointments and the reasonable draw on staff resources.

The most popular technologies that assistance was requested with were HTML/Javascript and Python. Fortunately, this played to our technical strengths.

While consultees were affiliated with a number of departments across the university, the most popular were Political Science, International Affairs, and Computer Science. Most consultees were undergraduate or graduate students, but also included some research assistants and faculty. Around two-thirds of the consultees had little or no programming experience.

Some of the more interesting topics included:

• Scraping legislation from another country’s parliamentary website and Security Council resolutions from the United Nations website
• Troubleshooting a web application used in a biology lab for quantifying the behavior of roundworms
• Troubleshooting a fluid mechanics visualization
• Building an online health survey with custom logic unavailable in current online poll sites
• Interview preparation for software development positions

By far the most significant issue we faced (about a half dozen instances over the semester) was computer science students requesting assistance with class assignments. In each case, we referred the student to her TA or suggested other resources (e.g., Lynda.com, to which the University subscribes). There were also some instances of requests for consultations on topics that should have gone to other library staff (e.g., for statistics consultations). We suspect that both of these issues could be handled through improvements to the Research Calendar and the information it provides users.

The software development consult pilot also produced some unexpected benefits. The publicity around the coding consults raised the general visibility of the STG group and resulted in some members of the GW community consulting us about matters that were in the purview of STG, but not the coding consult service. We built awareness in the GW community, including the University administration, that the Libraries had software development expertise and that libraries engage in software development as an activity supporting the University. As hoped, our increased interaction with the GW community provided us additional insight into needs we could potentially meet with workshops. It also provided each of us with learning opportunities, as we often had to sharpen our skills to provide assistance in technologies that we don’t use on a daily basis; additionally, we learned from each other as we would sometimes sit in on each other’s consultations.

Future plans

Given our experience with the pilot and suggestions we’ve received, we see some opportunities for improvement. In particular, we would like to:

• Perform outreach to department chairs as a means of reaching faculty and students and look for additional avenues for publicity.
• Consider a simple post-consultation survey and checking on outcomes with participants.
• Collect more consistent data on the appointments. In particular, it would be helpful to explicitly collect consultees’ departments, roles (undergraduate, graduate student, etc.), and programming experience.

Feedback on our initiative or sharing the experience with similar services at other institutions is welcome.

Overall, the authors consider the programming and software development coding consultations pilot a solid success. It achieved the goals of supporting academic or scholarly inquiry at GW which requires coding, while getting us away from our desks to interact with the GW community. Based on the pilot project, we plan to move forward with the software development consultations as an ongoing service of GW Libraries.

Acknowledgments

The authors would like to acknowledge the guidance and support of Geneva Henry, Hannah Sommers, Robin Delaloye, Matthew Mihalik, Dan Chudnov, the Reference and User Services librarians, and our STG colleagues.

About the Authors

Laura Wrubel (lwrubel@gwu.edu) is a Software Development Librarian at George Washington University Libraries.

Justin Littman (justinlittman@gwu.edu) is a Software Developer and Librarian at the George Washington University Libraries.

Daniel Kerchner (kerchner@gwu.edu) is a Senior Software Developer and Librarian at the George Washington University Libraries.