BY KATIE M.

One of my favorite presentations at Code4Lib 2017 was delivered by Kevin Beswick and Nushrat Khan, two librarians with the Digital Library Initiatives (DLI) department at North Carolina State University (NCSU) Libraries. Their talk, Fostering a Departmental Culture of Peer Mentorship in Software Development, covered programs created in response to the growing number of new professionals, student workers and full-time staff entering the library with a desire to advance their software development skills. This certainly isn’t unique to NCSU and in addition to my own experience, I was reminded of a report released last year which reflected on feedback from past National Digital Stewardship Residents. Many of the participants expressed an expectation that tech education would be a larger part of their residency through a mentor or other on-site resource. Dev skills are increasingly necessary in our field but the breadth of library science as a discipline doesn’t leave much room for a comprehensive computer science curriculum, which leads to a lot of independent learning.

My own solution was to pursue a ‘coding bootcamp’ during my fellowship with METRO, I found the teaching techniques to be novel and effective. After meeting at Code4Lib, Kevin and I decided to get together to compare learning methods employed at NCSU with those at code camp. Here’s what came up in our conversation:

[Katie] Let’s start with introductions! What led to your role as Digital Technologies Development Librarian?

[Kevin] I have a background in computer science and I joined NCSU Libraries four years ago as a fellow after graduating from the Masters of Library and Information Science program at the University of Western Ontario. Prior to that I was working at a small academic library at Laurentian University in Canada. I actually had a bit of trouble getting into the US initially because the job duties listed on my offer letter did not match up to the outdated job description of a librarian that the border guards were using as the basis for granting me a work visa. I explained to them that many of the services that libraries offer are now online, and my role as a librarian would be to create, develop and maintain those services. Evidently I could not convince the officers that I was in fact going to be employed as a librarian because I was detained for 4 hours, questioned aggressively, fingerprinted, and ultimately denied entry. Luckily, I was able to re-apply 2 weeks later under a different visa classification and everything worked out.

[Katie] Librarians are still going through this sort of identity crisis. I received my library science degree at Pratt Institute and in my last semester they decided to remove the word ‘library’ from the program title. Now it’s ‘School of Information.’ Digital Technologies Development Librarian kind of encompasses everything–how would you describe the role of the DLI department within the Library?

[Kevin] DLI is one of two IT-related departments in NCSU Libraries. Early on our Vice Provost & Director of Libraries, Susan Nutter, recognized the value of digital initiatives to the future of libraries. DLI was created to support this focus by bringing together a team from across the Libraries. Since then we have developed core strengths in systems analysis and software development. While the IT department in our library is responsible for managing core business services such as the ILS, catalog, electronic resources management system, patron computing, server infrastructure, etc, DLI is more focused on creating and supporting novel library services in collaboration with other library departments. Often, Digital Initiatives departments at other libraries will focus entirely on supporting digital special collections and archives, however our scope is more broad than that – we collaborate with every department in the library on projects. We bring expertise in systems analysis techniques and software development as tools to help solve these challenges.

[Katie] When did DLI become active with the Library’s fellows, and how does the program work?

[Kevin] The fellows program precursed our department, it’s been active now for over 20 years. The fellowship is open to new graduates from Library & Information Science programs, who are appointed as Librarians for a 2-year term, splitting their time between a home department and a strategic initiative that is typically in a different department. In their home department, fellows contribute to the department’s day-to-day projects and activities. Strategic initiative ideas are submitted by departments in advance of interviews, and align with the strategic priorities of the department itself as well as the Libraries as a whole. As part of the interview process, initiatives are pitched to candidates by supervisors, and candidates are encouraged to ask questions about the ones they are interested in. Fellows are matched with home departments and initiatives based on their interests and experience.

DLI tends to get new fellows within the department fairly regularly, and has a good history with fostering professional growth in terms of technology, but hasn’t offered many formal opportunities around this. There was a desire to learn more about software development and the tools/workflows surrounding it, so one day my colleague Bret Davidson and I thought it would be good to talk to the fellows about Git workflows, covering topics essential to working with others, like merging, branching and pull requests. The response was positive overall, so we decided to turn this into a series of software development discussions. We choose topics for future discussions as a group, and they tend to either come out of previous discussions organically, or suggested by someone in the group. So far, the topics have tended to be more around best practices, and about the software development ecosystem rather than core concepts like learning a language or framework – the types of things that newer developers may not be aware of or haven’t had time to really dig into yet. For example, we’ve done sessions on editor/shell configurations, package management, and how to effectively troubleshoot code problems. We try to make the format more of a discussion rather than a lecture, as we recognize that everyone has a different style of working, and brings different knowledge and perspectives to the table no matter their level of experience.

[Katie] The fellowship program sounds really similar to our reverse-pitch application process. I like that each department has a chance to get involved during the interview process because it forms an internal community around the fellows–multiple parties are interested and invested. What are some examples of past or current projects?

[Kevin] Nushrat Khan, who presented with me and who is a home department fellow in DLI, is working on an initiative in the Acquisitions & Discovery department that explores linked data and the semantic web. She has been spending time performing an environmental scan in this area, and conducting interviews with other departments in the library to understand their needs and identify potential opportunities for collaboration on future projects. In DLI, Eka Grguric has been working on an initiative relating to Open Science and how we can provide support for researchers on campus who are interested in applying these principles to their work. Some outcomes from that initiative have been the development of a workshop series around tools that support open science practice. We’ve also had fellows work on initiatives related to creating programming for and building a community around a makerspace that we’ve opened, creating new workflows for born digital content, creating a program around web archiving to name a few others.

[Katie] You’ve described the focus of all three of our fellowship projects at METRO this year! What kind of learning strategies have generated positive responses?

[Kevin] We currently are doing group discussions, peer to peer consultation, code reviews, and compiling lists of technical resources to assist in learning skills that will help fellows in their future professional careers. We’re furthest along with the discussion series as a program currently, and I think that what started as an opportunity to build skills in software development and be exposed to new approaches or tools has really become something more valuable. In preparing for our presentation, we talked to everyone who has participated in these discussions to learn how it has affected them personally as well as the general culture of the department. We learned that it made them feel that experienced developers were more accessible, and increased their comfort level in asking technical questions to other people in the department. It helped the group become comfortable with one another, and work better together.

Another goal we try to achieve through this is to demystify our work and the development process in general. By leaving these sessions on the more informal side, we can help to expose the real side of doing this kind of work, and figure things out together. I think that the experience of watching a conference presentation, or looking at code for a mature product on GitHub might lead people to believe that developers are magical creatures that can write clean and functional code with relative ease, and never run into problems. This is quite the opposite from the real process, and we try to highlight that by making minimal preparations for each session. We usually base discussions around a relatively lightweight document with a few bullet points, and we try to come with hands-on work that we haven’t done before so we can all experience the process of working through it together. We recently did an introduction to Vagrant and Ansible where we built and provisioned a virtual development server for a small project that none of us really had any experience with. In addition to learning about the technologies and why they are useful, everyone was able to see the real-life process in putting this together and were able to participate in troubleshooting issues.

[Katie] Okay, last question! How do you see other libraries or organizations providing the same kind of support as DLI at NCSU?

[Kevin] We’re lucky to have a department that is big enough to support these types of initiatives. I’ve worked in a smaller library before where there was only one other person who was responsible for technical work. While they were a great mentor that I owe most of my early successes to, it is harder in that type of environment to find communities for peer mentorship. A lot of people in smaller libraries may even be the sole person working on technology-related projects. This has gotten me thinking about opportunities for remote peer mentorship around software development in libraries, and how they could be offered in an effective way. I’ve participated in a remote mentorship program as a mentor before, but there seemed to be very few participants and it didn’t seem like many connections were being made between mentors and mentees. I think the biggest thing that was missing from it was the relationship building component. In order to have a good mentor/mentee relationship, I think trust needs to be established along with some comfort level between the people participating. If we could figure out how to improve that aspect in a remote situation, figuring out the logistical details of making something like this work for software development would likely be trivial in comparison. I’m interested in learning about models where remote mentorship has been successful in the software world and seeing if there are any lessons we can bring back to the library technology community.

---

Time to switch up interviewer/interviewee roles!

---

[Kevin] I have been hearing a lot lately about developer bootcamps as a way to build development skills, but I don’t really know much about them. I was very interested to hear that you were currently enrolled in one! What is the typical format of one of these programs? What is tuition cost like?

[Katie] So, private schools focused on teaching professional web developer tools began opening circa 2012 because there was a demand for skills that most formal education neglected to teach outside of CS degrees.

I found that courses vary by school but most include a full-stack intensive that incorporates front-end and back-end technologies through lessons in HTML & CSS, Javascript, Node.JS, React, Ruby on Rails. Surprisingly, soft skills, like how to work on a dev team and learn new languages to stay tech-relevant, are really emphasized.

These typically run between 3-5 months with costs running an average of $2k-$4k for a language based course (eg: javascript, ruby), or $10k-$15k for full-stack. That cost is pretty steep but I found that each site offers options for tuition payments, as well as diversity scholarships and funding for women applicants (General Assembly was a notable exception to this). Grace Hopper Academy is also an option as a women-only code school with deferred tuition that is owed after landing a dev job, but the cost was considerably higher than average.

[Kevin] It is great that most of these programs are putting an emphasis on this issue, and are trying to make them more accessible to women and minorities. Which code school are you enrolled in? Do these programs mostly take place online, or in-person?

[Katie] I went with Dev Bootcamp (DBC) because it had the best combination of schedule/class choice/cost/ratings. It splits the coursework between remote learning and on-site work at a Manhattan campus, which is what most schools provide in cities across both coasts. In terms of how classes are taught, I can only speak to the remote coursework since I’ve yet to reach the on-site intensive portion, but currently, this takes anywhere from 8-15 hours a week. There are also people who are taking a full time approach to this and spending their days deep diving with supplemental learning (like rubymonk, codewars, etc.).

[Kevin] How is the curriculum structured? What does a typical week look like?

[Katie] Classes build in intensity and in mine, the first weeks were spent introducing version control and Git workflow, command line, CSS, HTML, moving into Ruby.  These are taught through a series of challenges set up through 5-10 minute videos accompanied by written tutorials developed by DBC instructors.

There are also peer ‘pairing’ sessions that I find to be really helpful and fun. Twice a week you get together with a student via video chat and share your screen to work work through a code challenge together (we mainly use Google Hangouts). Students are located in cities across the United States, and sometimes even abroad (I paired with someone in Berlin last week). They can be anywhere for the remote period. At the start of a pairing, we determine who will be a ‘navigator’ vs. ‘driver.’ The navigator reads through a code challenge while the driver works in Sublime, command line, etc. Often there are aspects of the challenge that have not yet been directly addressed in our lessons, encouraging us to develop online research skills. Overall, this teaches you how to work with a wide range of personalities and causes you to recognize how different people approach both teaching and learning.

Once a week a pairing session will include an instructor who is present to watch as you and another student work, stepping in only if they see an easier approach to a challenge or want to clear up a question. Instructors are also available through a Slack channel we use to post questions and share resources between the cohort. Oh, and there are also daily ‘office hours’ that involve joining students in a video chat where a teacher will be reviewing methods from the week.

[Kevin] It sounds like the curriculum is designed to encourage collaboration and peer mentorship. How does this work out in practice? Are instructors and other students approachable and receptive to questions, or feedback?

[Katie] Peer mentorship is definitely a large part of the program. An unexpected side of dev school is the attention given to behavioral learning. In the first weeks, we were assigned several videos based on psychology studies covering ideas about fixed vs. growth mindset, leadership skills, and the ways different personalities might respond to social or professional challenges. This was meant to assist us with pairing sessions. For example, we are asked to get in the habit of going through introductions at the start of a code challenge to share insight into our mood or feelings about that week’s lessons. You go through this again at the end of the session during an evaluation of your partner’s work when the assignment is completed. Remarks are supposed to include actionable, specific and kind (ASK) feedback regarding their code or their ability to work with you. Theoretically, this improves your habits while working with a development team and although it might seem a little overboard, it quickly becomes normal and is a nice way to remind yourself to be aware of your own behavior.

---

For more information:

Kevin Beswick’s contact info can be found here or tweet him @kbeswick.
You can also read about the Digital Library Initiatives Department @ NCSU here.
Or, spend more time checking out Dev Bootcamp!