Select Page
Learning NLTK in Python with Jupyter notebooks

Even though learning new technologies and tech skills is one of my favorite things to do, and it’s one of the things regularly I teach students, it is still SO HARD! Attending the Digital Humanities Research Institute in the last two weeks has reiterated this for me. I’ve attended several immersive trainings for digital literacies and technologies (some very good, and some not so much), and DHRI stood out to me. Here are my reflections on why that might have been so.

The “why”

Early on in the institute, Lisa Rhody, the Project Director, noted that previous participants expressed frustrations when they weren’t allotted time to discuss why things worked they way they did, why it was important to know this text-based editor when there were so many other other “easier” web-based applications out there, why this would be a building block for another skill, and so on. This “why” is obvious when teaching information literacy. Why you should consider some editions over others, why these search terms are more productive than others, why should you articulate a research question are things we discuss. But in some ways I’m still discovering the “why” of certain applications, and why some things work and some don’t.

Building “the why” into learning about tech literacies and applications is often obfuscated, saved until the end, or explained with an insider’s perspective. And there is so much consideration of your audience that has to go into this explanation, as well. “Why” matters so differently to different people! The faculty and leaders at DHRI made sure to explain “why” frequently, early, and in ways that didn’t just make sense to themselves.

Break it on purpose

Error messages in the Python interpreter (git bash)

The graduate fellows leading the Python workshops asked us to spend a portion of the workshop trying to create error messages that resulted from our coding. I found this difficult for 2 reasons. First, figuring out what lay outside the bounds of a new language was a different approach to learning the rules of this language, which is usually how language learning is taught! Unlike learning Spanish or French, you can still communicate with wrong syntax and punctuation. Computers do not work this way! (“Computers are not smart” was one of our mantras.) Even though there’s often more than one way to say something, you still cannot communicate outside of the normal structures of language with coding languages, so doing it on purpose was incredibly helpful, albeit challenging.

The other reason why this was difficult (but necessary!) was because in addition to speaking this new language, we also had to do some interpreting whenever our code threw an error message. One of the fellows, Rafael, showed us how to understand these errors by deconstructing the syntax of them, and modeling how to search for answers. Rafael also repeated that “error messages are our friends,” because the computer, in its computer-y way, tells you what it was unable to interpret. Through this, I gained some comprehension, but more importantly, I felt more confident that I could move forward.

Pacing and chunks

Each of the lessons in the DHRI Curriculum was

  • preceded by contextual information (“the why”),
  • was accompanied by ethical considerations of the potential consequences of using the technology without including its human-interaction component, and
  • was divided into easily digestible portions, all of which preceded short and varied formative assessments.

And DHRI fellows told us to work on these lessons before discussing them in person. In my own instruction, I have felt myself rush through a concept in order to squeeze all of the bits and pieces of software into one session, which I know is not good practice, and yet…

These online lessons allow for self-pacing and reiteration, are “chunked” into small-but-important concepts that are then assessed, and allow the in-person instruction to focus on what the learners are struggling with in that moment, rather than finishing a pre-determined lesson. Sometimes the solution is simple! If the full lesson is online and portioned into short lessons, students can work past the meetings on their own time and at their own pace.

Emphasis on the local

Screenshot from the DHRI Network webpage.

DHRI is also built on the principle of building local networks by bringing the experiences from DHRI to attendees’ different settings — at their own institutions, in their own neighborhoods, and on their own devices, and this was reinforced because we attended from our individual locations, virtually. This forced me to consider things on a different level that my own students might be working through. What executes successfully within your firewalls? What does this screen look like on a Mac vs. PC? What can you accomplish within your literal and metaphorical bandwidth? Additionally, the fellows held office hours before the institute started every day to meet with attendees one-on-one and work through installation issues, error messages, and then some.

Even though many of the students we work with are down the street from us, they are operating under different local restraints than I am. Providing them with a support network (each other, myself after class, static help pages, context, alternatives!) is essential to feeling confident while learning new technologies, and confidence itself is key to interacting at all.

What I’m doing differently this time

  1. Before launching into a step-by-step or the layout of a new platform, I’m going to make sure students understand why before how. Why does this matter? Why are we doing it this way? Why? My 4 year old will be so proud.
  2. I am still not, by any stretch, an expert in coding languages, but I do work with technologies that fail. So I’m going to create space and time to decipher and comprehend these failures with my students. Why didn’t this render? What should I do differently? And with some demonstrations, the answer will be “I don’t know,” but I know that allotting time to discuss the failure is important to understanding computer operations and building confidence.
  3. The lessons and lectures that previously happened in class will come from a static place (currently under construction) that allows students to rinse, lather, and repeat. In class, we will go over more difficult concepts in those lessons, but focus our scheduled time together on working through what’s most important.
  4. I will give more channels for finding support when we are not meeting. I always emphasized seeking support as a self-lead endeavor in the past, but going forward, mediating these referrals will be a part of that process. In other words, here is how you search this documentation for the resolution to this error message; here’s when I’m available outside of class…let’s schedule a meeting; share your contact information with your group members now, and schedule a time when you’ll meet to work on this project.
dhri | digital pedagogy