It's the night before the semester begins and you can't sleep for worrying about tomorrow's class. The first day is often nerve-racking; it's a critical moment to set the tone for the semester and shape student expectations. In this section, our respondents discuss their different approaches to teaching that first class of the term.
On the first day of the School for Poetic Computation we start with questions, and it is really fascinating. We teachers come in and explain a little bit about what we do and I ask students to take 20–30 minutes by themselves and write down every single question that they have. And this creates a really interesting and really strange moment. I want to know whatever has brought them into the classroom and what questions they had in mind. These questions become signposts or markers for what we talk about. So someone will say, “I want to learn about X, Y, Z,” and someone else will put up a response saying, “Come talk to me.” Some questions are unanswerable, like really deep and profound questions, and I love that some students will try and cross questions off the list as the class progresses. I think it's important grounding. A lot of times you come into the classroom and the professor gives you a syllabus and it's like: here's where you're going to go, here's the journey we are going to take, we're going to cover these things to get to that point. So it's nice to start on the first day and say: “What we are going to do here is really driven by questions, driven by a collective exploration of questioning.”
On the first day, I always feel very anxious all morning before class. I wonder, “What am I going to do for two and a half hours? I mean, that's so much time!” And then I over-prepare and inevitably only get to like a tenth of what I meant to. It's different in different contexts, but one of the things that I do if possible is to not look at any code until the last five minutes of class, if at all. In the past I've done a conditional drawing exercise, where the students pair up and one writes instructions that the other has to draw.
Another thing that I also do is try to have a discussion about historical context, programming languages, and what it means to program. Like, why should you program? If I'm in a class of true beginners, I like to talk about what programming languages the students have heard of and what they think people do with them. I ground everybody in a larger landscape, which is a nice thing to do.
What I also find is useful is to show work people have made in previous years and to really focus on projects that do some social good, or projects that just have this totally nonsensical, playful quality with no practical value whatsoever. It's easy to imagine certain kinds of interactive exhibits or certain kinds of games, so I try to showcase projects that are a bit different. One thing that I have become much more conscious about recently is making sure that…I have a diverse set of people who've made the projects: from different communities, different genders.
I like to tell a lot of jokes that nobody gets, and if I keep it up, by Week 7 I might at least get a pity laugh. In the introductory class we do a lot of borrowed things, like “Conditional Design” drawing exercises, which is also something Casey Reas does. If I'm teaching JavaScript, we pull up an example online and I show them how to open the console and start messing with the JavaScript or CSS that's running to get to the idea that it is all hackable. I also try to ask who's feeling nervous or scared or unhappy or thinks they're going to be bad at this class. I think a lot of times everyone comes in thinking that they're the worst student in the class or that they're the only one who is not going to get it, and sometimes I think that it is reassuring to see that everyone is terrified.
Our Social Hacking class [taught with Kyle McDonald] has special requirements. On the very first day, we have students sign a contract that says a few things. Firstly, that we are asking them to experiment but that they acknowledge that the experiments are theirs so we're not liable for their decisions. Also that they take into consideration that they are doing work that involves other people and that just because these may be art projects, that doesn't give license to not respect a person. Also that they acknowledge that we are asking them to take risks and they must be willing to do that or otherwise they should drop the class. Then lastly, that as everyone is taking risks, we need to respect that and not shut anyone down for doing so and rather we each need to respond to this. In this class everyone puts themselves out there, and so we all need to put ourselves out there by giving feedback about how other people's work makes us feel.
I usually explain the intention of why I choose to work with particular tools. We talk about how there are different coding languages and different coding editors and I will talk about why I chose GitLab to host my syllabus. Why did I choose to work with p5.js? What are the priorities of this software and how are values embedded in software? In a way, choosing a tool is a kind of politics and I want to set the scene that the course is not about picking something because it is efficient or good and then just using it. I want to ask why you are using it and what kind of values you are subscribing to. I think that is quite important.
The second thing is more about creating a space for them to speak. A lot of them have no programming experience and they usually come with a lot of fear and anxiety. I am very particular and I ask them to say something about their feelings about code. I want to focus on feelings and the emotions attached to coding, rather than on “why I want to learn C++” and so on. At the end of the course in the year before, I always ask the students for a sentence on a Post-It note on what they want to channel to the students in the coming year. How do you want them to prepare for this course? Usually there are comments like, “Coding can be queer.” “Be open.” “Coding can be something very fun and conceptual.” “Don't expect code to always work.” They see these Post-its with their peers’ words and it's much more convincing than me saying these things. I usually stick them on the wall and ask them to come and take a look. I want to set the scene that this is a rigorous course, it's difficult, but you are not alone. If we work together, you can pass through this just like these students who are able to give you this advice.
The third thing I find very useful is to ask them to think about a reason to attend this course, beyond that it is mandatory. As coders and teachers, we know that this stuff is not easy. If they have zero coding experience, it's going to be difficult to sustain their motivation throughout the entire course. So I want them to think in the first class of why this is beneficial for them, e.g., I can get a better job, I can communicate between programmers and business leaders, or I can understand the black box of computing culture. Whatever it is. They need to have a reason. I then emphasize this in a lighthearted way. I tell them: remember what you have written down and keep this motivation. If you feel fear or anxiety about your work, get these words out again and look at them and think about why you want to learn and why you were once motivated. This will be a helpful tool to pass through the difficult times.
I try very hard to prepare them psychologically for this challenging class and remind them that we will work together. This is the difference between an engineering class and a non-engineering class. For engineering and CS students, they have the motivation to learn coding; they want to be programmers. But for arts and humanities students, they are scared of this weird language. And you have to find a way to bridge that.
We talk about conceptual art and code as an instruction-based medium. Then I have one student stand at the board with a marker, and then the other students instruct them how to draw something…we go around the classroom and the students each give an instruction to the person. It's fun and it helps them think about how specific or not specific their instructions are.
I'm really aggressive on that first day and we do a lot of things. At that point, everyone's brains are so pliable because it's all foreign…. I've found that the longer I wait to get to the trickier stuff, the harder a time they have with it. Things start to calcify in their brains, and that flexibility they had on the first day disappears because they are building these constructs. If I wait until the fourth session to talk about what a class might look like or what an object is, by that time they are like, “Wait, wait, wait, no, this doesn't mesh with the construct that I've built in my brain around this.” So if you put it in the first day, you don't have to teach it really heavily and they are like “Oh. Okay, that's how this works.”
Golan Levin: What about the first day of an intermediate studio in information visualization? What does that look like for you?
My information visualization class is half theory and half practice, and there we take a pretty different tack. On the first day in the first half of the class, I write the word “data” up on the board and we talk about what that word means, which is actually an incredible little rabbit hole. Everyone thinks they know what it means, but nobody actually knows what it means. Then we really talk about “Where does data come from? What does that process mean? What is it? How does it manifest? What do we do with it?” What I'm trying to do is I'm trying to get them to define what I think of as the data pipeline. Data is the result of measurement, and we then parse that data using computers in some way, and then there's a representation step. I want them to make that map for me, to start identifying interesting places to intervene. For me, a data class is not about that representation piece; it's about the other pieces because I think they're so much more interesting.
In the second half of that first day, I try to get the students to create a dataset on the fly and think about what that means. A simple one is asking students to say what they think their level of programming skill is between 0 and 10. Then we take those 16 answers and do a very simple plot of them, and then we come back and say, “What would have happened if I would have asked this question differently? What would have happened if I would have given you a clearer way to bound [your answer]? What would have happened if I allowed you to share, if the first person read their answer aloud, and then the second person had to base their answer on that person?” This gives the idea that these numbers already carry a fantastic amount of bias. Even in a really simple exercise like that, you can't really do it the “right way.” We can talk all we want about how to represent that data, but actually there are a million things that have happened in producing it that have as much of an effect, if not more of an effect, on what end the reader will see.
I usually prepare a pretty long lecture. This gets the students who are into it excited, and also shows what the class is about to the ones who are not into it so that they can see my lecture and leave. I think this is a really good thing. Also, when I write the course description, it's usually like four months before the course actually starts and my idea of the class was completely different [then]. This then becomes a chance for me to realign what I want to do and what students think the class is. I rarely teach technical courses now, but when I do, it's usually contextualized, so it has some conceptual arc. I explain what I can teach and what students need to learn on their own. I try to make it clear that learning technique is really hard, and it's dependent on where you're coming from. I don't try to give them the expectation that they'll be good at technical stuff by the end of the course.
I try to demystify their fears, and let them know that it's not magical and that it takes what I call “butt-in-seat time.” You just have to really spend the time to either watch Dan Shiffman's videos, or read out of the Learning Processing book. I cover more of the philosophy behind programming. I also sort of quiz them and ask them why are they here, beyond the class being a requirement. I want to know their expectations, and I try to get a sense of what their programming background is. We don't talk about code or anything until probably the third class. The very first assignment I give is actually having the students create directions for something that they do in life, just written instructions….I make them do that before we even start talking about code to draw upon the point that the computer only does what you tell it to do….They then have another classmate execute those instructions, but they can't discuss it. Like the person writing the rules can't talk to the person executing them. The person who wrote the rules can observe and then modify the written rules to improve the outcome. I find that a very useful prompt for getting people used to the idea that if you're not very direct and literal in your language, then the program won't execute, and it's usually because you haven't broken it down in enough steps.
Don't be a maniac. The beginning of a class is very important. The students’ first touch and first experience with code makes a big impression. Although as a teacher you want to show your students that you have a deep knowledge of the material, it's more important to go slowly and casually, and stay open to where they are at.
I remind them that they are in the beginning of a semester course. They are basically safe from thinking too much because I'm going to take away, I'm going to put so many constraints on them in the assignments in the beginning that their creative freedom is very small. So the first assignment we do is at the end of the very first class. I tell them to design an ice cream cone using a triangle, an ellipse, and a rectangle, in black and white only. If you're young and you're a student and you've never designed before, which many of my students haven't, the whole palette of everything that can be done is just way too big. So I try to impose core constraints and have them work on very specific things. Like, how to position three basic shapes. How do I make it say “ice cream cone”? How can I make it say “sad” or “happy”? So the first class is very much about, “You're here. Don't feel bad about not knowing things, because I will make the assignments so simple, that at least in the beginning there's nothing to worry about.”
In my text processing classes, I take them straight into the UNIX command line tools. I do this because the people who take my classes usually have an OSX computer, so they have all these tools already built-in and the UNIX command line has this reputation of being super forbidding and difficult to get into, or for hackers only….Once they know how to open this imposing terminal window and then type something into it and make something happen, it instantly feels good to be able to add that to your repertoire. I focus on the command-line text processing tools, tools like grep, head, and tail and other commands that are for transforming text in addition to tools for searching. I relate that back to a conceptual presentation, where we talk about work from the Dada movement, conceptual writers, and poetry from L=A=N=G=U=A=G=E [an avant-garde poetry magazine, published between 1978 and 1981]—here's how you can either repeat these methodologies or their aesthetics using these tools that are already on your computer and that really are wonderful to use. Of course, I also cover what the class is going to be about, but [learning about the UNIX command line] makes them feel powerful and like they have dug into something that's unique to this particular class.