Digital Methods

Course Format and Materials

Class sessions will very in format, moving between lecture, code walkthroughs, and hands-on exercises. (For how all of this adds up to a grade, see (Un)Grading; for when and how we use AI, see AI Policies for an AI Course.)

The Heart of the Course: Your Research Project

This entire course revolves around a research project on a topic of your own choosing, which you will start working on almost immediately. Most recitation sessions will be devoted to project work, sometimes in a structured manner with specific assignments meant to advance your project progress, and sometimes as discretionary time (in addition to your weekly project meetings, separate from class).

In Class

Typical in-class activities include:

  • Coding walkthrough: Guided discussion of the features of complex code, aimed to increase general literacy.
  • Digital humanities lecture: Conceptual coverage of computational methods and AI as a field of inquiry.
  • Coding without computers. Quizzes and exercises on paper that drive home core concepts and coding literacy: functions, paths, loops, and the like (see Pen and Paper).
  • Project showcases. We look at digital humanities projects, figure out how they were built, and consider the research questions behind them, and what they suggest for yours.
  • Hands-on work, machines open, on code and on your project.

Recitations

There are two recitation sessions each week. Choose one; you are welcome to attend both, and /or are at liberty to switch at the last minute without notifying an instructor (though you should keep your team members posted). Many recitations are dedicated to project meetings, so do your very best to make sure that everyone on your project team attends the same one. Don’t worry about registration: you are free to switch between them as you see fit.

Homework

Coding Assignments

Coding assignments in this course are a technique for learning, not, as in many other courses, a test of whether you have already learned something covered in class. A crucial skill in the digital humanities is figuring out how to do something you don’t yet know how to do, so these assignments will often ask you to write code you do not yet know how to write. If you are used to homework-as-test, this may feel disconcerting (“But they haven’t told us how to do this!”). Professional developers look things up all the time, and learning how to find answers, in references, online, and with AI, is one of the goals of this course.

AI on or off. By default, you may use AI on coding assignments. When an assignment asks you not to, it will say so plainly. Either way, you are responsible for the code you submit (see AI Policies for an AI Course).

Getting stuck. There will be times when you don’t get the result you want. In those cases, submit what you have, along with a description of what you tried, what you expected, what you got, and what you think went wrong. That counts as completing the assignment. Getting stuck is part of learning, and the TAs and I are happy to help unstick you once you have described the problem and your own attempts to solve it.

Comment your code. Every coding assignment must include at least one relevant, thoughtful comment, written directly in your file as a formal code comment (we’ll show you how), not in a Canvas comment box. This builds the habit of reading, and explaining, the code you use.

Assignments and Feedback: Links to all assignments are on the syllabus. Some assignment descriptions live on Obdurodon, some on this site, and some on Canvas. Don’t wait for an assignment to appear on Canvas to get started, even though Canvas is where you submit it. In some cases, we will post an answer key and discussion.

Reflection Assignments

Reflection assignments usually take the form of special entries in your Worm Journal. For instance, we might ask you to look at how other digital humanities projects pursued their research, and what lessons they hold for your own project. Or we might prompt you to think about how digital methods, and AI in particular, are changing our society, and especially research in the humanities.

A reflection does not have to be long, but it should show real thought. Don’t summarize an article (which you could do by skimming the first paragraph), and don’t just praise or condemn a project without getting specific about what works, what doesn’t, and why. Some projects matter for their design, others for their research methodology; engage with whatever is most significant about the one in front of you.

Periodically, we will ask you to submit scans of your handwritten reflections to Canvas (so that you can keep your journal with you, and so that we have a joint record). You will need some way of turning paper into a PDF: a scanning app on your phone is fine, and most phones have one built in (see Getting Set Up).

Capstone Coding Assignments

At the end of each unit there is a capstone coding assignment: a longer piece of work that pulls together what the unit covered and asks you to show that you can use it. They are announced on the syllabus. Most are take-home, and their format varies, but usually they are no AI and no notes. A capstone comes back with feedback on each part, but no grade. Its job is to show you where things stand, and you can draw on it when you assess your own work at the end of the semester (see (Un)Grading).

Help, Collaboration, and the Course Forum

Coding was never a solitary pursuit, and even less so now with “friends” like Claude. Collaboration is welcome. You can always ask for help: from the TAs, from me, and from your classmates. A lot of the time you will also be consulting online resources and AI.

Despite the image of the programmer as a solitary soul hunched over a glowing screen, programming is a social activity, and real programmers make liberal use of discussion forums to ask and answer questions. Ours lives on GitHub, which is where those conversations actually happen in the wild, and where the code we hand out lives. Everyone sets up a GitHub account in the first week (see Getting Set Up). You do not need to learn Git to use the forum: it is a web page with comment boxes on it.

That gets you two things. You can ask about course code in the place where the code is, rather than describing it from memory: comment on the line that is giving you trouble, and whoever answers is looking at exactly what you are looking at. And when you want help with your own work, you can @-mention an instructor on your own repository, so that we can read the actual file instead of a screenshot of it.

The forum is entirely optional but encouraged: don’t be shy about asking questions there, and don’t be shy about answering them, which is both good citizenship and satisfying. Your contributions are also evidence of engagement that you can point to in your final report.

What You Need

A computer of your own. We assume you have regular access to a computer and can bring one to every class: we do not meet in a computer classroom, so whatever you bring is your lab. If that is not the case, talk to me or one of the TAs. There are various solutions at Pitt.

Software. All of it is free to you. For installation, see Getting Set Up.

  • VS Code, with GitHub Copilot (see Tools).
  • oXygen XML Editor, through Pitt’s license. Installation instructions and the license key are on Canvas.
  • Python (via Anaconda) later in the semester, with details announced in class.

Reference. Obdurodon is the course’s encyclopedia: tutorials, explanations, and many of the assignments.