Things I Learned From Co-Convening An Interdisciplinary, Interyear Course

I’ve written a bit about Textlab before (here & here), but as my third time teaching it winds down, I’ve been thinking a lot about the various challenges that come with this course. At the risk of repeating myself, this course is sponsored by the Vertically-Integrated Projects initiative at my university, and is one of several (currently 8, I think) projects running. This structure has been borrowed from the Georgia Institute of Technology and has been running at Strathclyde for the past three years.

Textlab was one of first round of projects to be launched, building off work with Visualizing English Print. Jonathan Hope, Anouk Lang, George Weir, Richard Jason Whitt and I co-designed a course for English studies students and computer science students to collaboratively work as a microcosm of the Visualizing English Print project over the course of a term. Admittedly, this class is kind of a strange beast for all involved, including us.

Over the past three years, some things have changed quite a lot from our initial course plan and some things haven’t changed at all. Some challenges remain challenges and some kinks have been ironed out, but here’s some things I learned from co-convening this course:

    Interdisciplinary work is best done when there is an infrastructure for it. We don’t currently have a general education structure in place for undergraduates. Though I suspect the sciences have more cross-faculty students than English and Computer Science tend to, this makes registration and ensuring all students get the appropriate number of credits, with everyone teaching affected courses aware of our system into a bit of a nightmare. Furthermore, depending on which department is leading the course (this year it’s CIS; previously it’s been English), at least half of the students on the course are lost at sea because the other department doesn’t know what to do with them or what their course requirements are.
    It’s my understanding that the university is trying to hire someone whose entire job would be doing administration for the Vertically Integrated Projects and taking care of these tasks, but in the meantime, there is no structure and that’s not great for the students (or us).
    Too many modalities are overwhelming. Giving students lots of small tasks to do, like blogging, tweeting, recording, writing, and reading, is great because it requires time management skills and genreblending. But eventually that’s just too much to grapple with. This is a difficult class to begin with! I’m not sure how useful it is for students to have to write performatively for the public alongside getting to terms with new software, new methods, and new approaches to something they are only semifamiliar with AT BEST. This is not to say my students are stupid – quite the opposite – but that giving them too much new stuff to do is just really overwhelming. How do you know what to focus energies on when there’s so much to address? Over time, we’ve scaled back a lot in our course expectations, which is something I think is really good. It gives the students scope to focus on their work, and once they feel they have a grasp on it, THEN they can start disseminating in really exciting and productive ways.
    Speaking of Structure… When we started Textlab, we gave the students minimal instruction but lots of software, with the model of the VIPs being that “students are smart. Give them the tools, and set them off; they’ll do great things.” Our students did, and continue to do, great things – but the minimal instruction is extremely frustrating for the students. We (I hope) make it clear that this is a research-driven course from the beginning, and that they are expected to be self-driven and relatively autonomous. We’re there to help, obviously, but it’s not really our project, it’s theirs, and they have to make their own decisions about what is useful and what is not.
    Similarly: Too many cooks spoil a dish vs a pot without water will never boil. We very quickly realized in the first year of Textlab that having upwards of 5 people roaming around trying to help wasn’t really helpful, because everyone would make very different suggestions and the students were totally lost when it came to figuring out what to address first. To rectify this in the second iteration of Textlab we instituted a “the less we say the better” policy: we showed them software and told them to figure out what to do with it. There are pros and cons to both pedagogical approaches, but as a middle ground this year we tried worksheets with guided exercises to introduce the students to the software. From my perspective as teacher this seemed pretty successful as long as at least one of the staff members was on-hand to address questions, which requires the students to feel comfortable asking us for help.
    Different departments do coursework differently. This comes as no surprise (I hope). Computer science labs generally involve a task or two to solve in a given lab time, but you can do it on your own time if you wish, as long as you practice and understand the concepts discussed. Contrast this with English studies discussion sections, which are often lead by someone, very often require the full allocated time, and are less about the hands-on, practical implication of a concept and more of an abstract unpacking of a concept or text.
    Combining these two approaches in a lab setting is a challenge: how do you get the students to reach a middle ground? I’m not sure we ever really solved this problem: we can’t make students stay in a classroom, especially not when it’s research-driven and we can’t quite tell them they’re not required to show up as long as they do the work. Our solution was to put students into small groups, assign them a play to work on, and offer them lab space once a week for 2-3 hours to let them work out what needs to be done from there with available staff support. A lot of this course is achieved outside of class, which requires everyone’s schedules to mesh a least a little bit. Even trying to get a class time that didn’t clash with both faculties timetables was difficult.
    Groupwork: still not a lot of fun. Look, I hated groupwork as an undergraduate, and I totally cannot blame anyone for not liking it: suddenly your success in a course is dependent on one to four other people who are not you. This sucks. To account for this we had students fill out a sheet where they would independently report on their group’s participation. If a five person group had labor split evenly, great, they’d get the same mark for participation. If everyone agrees that someone doesn’t pull their weight, then the participation mark for that person goes down while everyone else’s would go up. Etc.
    Different departments have different kinds of students enrolled. Again, I hope this is a no duh moment, but the kind of student who wants a computer science degree is going to have different interests than a student who wants to get a degree in English. In the first two weeks of Textlab this year, two separate computer science students approached me to say they had done extracurricular tech work: one taught themselves Python and was concerned that Unix was too far removed from their needs whereas another had installed Ubuntu on their computer to feel more comfortable using the bash shell. Maybe I’m not a good English teacher (this is likely) but no student has ever come up to me after teaching a Milton poem to say “I liked that so much I read all of Paradise Lost for fun”. Again, maybe (probably) this is my fault, but I also suspect that the oh factor for humanities students comes much later, after the class is done: “I really liked that class and now I want to know more.”
    The beast factor makes this totally worth it. Our students learn a ton in a very short period of time and can talk in depth about very complex concepts including linguistics and statistics without having to ever make it explicit that’s what’s going on. The technologically-shy leave a lot more confident in their abilities and the technologically-savvy learn about a practical application of skills on a real-life project. Each subset of students gets to learn from the other – and it’s not just content but also communication skills and time management. But most importantly, each student who leaves this class has achieved something very significant, and have something amazing to put on a CV: imagine asking them to explain something they found challenging in a job interview!