What's your advice for educators teaching arts-programming for the first time?
In teaching media artists and computational designers, we need to cultivate multiple skills: a sharp eye, a critical perspective, technological craft, and passion for the field. And we must support the student's ability to connect these capabilities in practice. The following conversations navigate this terrain, outlining a range of tactics, tips, and lessons learned the hard way.
When teaching programming to non-programmers, and specifically to designers and artists, I think it's really important to say in the beginning, “My intent here is not to make you into a programmer. I think you should continue being a printmaker, or a typographer or whatever you are. My intent is to give you some computational tools that will help you.” Also, get your students making things as soon as you can. For me that has to be ten minutes into the class. We write a really simple four-line Processing sketch that does something really easy and gets them there right away. Don't stop to talk about what the IDE is and what syntax looks like, or what a semicolon means. That stuff sucks. You need it but it sucks. Do the making first, then use that to go back and talk about it after.
Every time I give out homework, I always say that every homework assignment is an opportunity for genius. The most important advice is to have that sort of optimism, to have that sort of energy for your students with every prompt and every time you ask them to do something or engage in something. Learning code can be frustrating and it requires a lot of time and a lot of failure. Time and failure and misunderstanding. To imbue a sense of optimism here is so important—to celebrate this as a new mode of working and to help students to realize that there's all these untapped ideas out there. Also, anything that can turn the classroom into a mini film festival is really great. I think it's important as a teacher to show what you're curious about, to show what inspires you, and to be able to talk elegantly or passionately about what moves you, as that helps students articulate what moves them. By showing these references and using them as a context to talk about code, it can help students translate and articulate what they care about.
Something that I read that really stuck with me is that as soon as you figure out something that was confusing you, your brain immediately forgets what it feels like to be confused. Your synapses will fire in a way so that you're not confused anymore. So you learn to code and it clicks. You ride a bike, and then you can't remember how to not ride a bike and for that reason, it's sometimes really hard to remember that feeling of confusion. So…before office hours, I try to think about something that's really confusing, or I try to imagine myself back in the lab as a student. I really try to tap into that feeling of frustration, that confusion when things don't just click….By trying to take yourself back there as a teacher, particularly if there's a lot of students you need to help, it helps you connect with them more.
Tega Brain: That's fascinating. There have been times when teaching a class for the first time where I've received some unexpectedly good results and reviews, especially for material slightly outside my skill set. Then once I've taught it a few more times and I know the material really well, I think it gets harder to empathize. After those first couple of times I often feel like I'm actually getting worse at teaching it, which is really not intuitive. So as first-time educators your inexperience can actually be a positive thing, because you are more likely to relate to students and understand what they are going through.
Totally. I think the other thing is just modeling belief, as this can change a student's world. I think probably everyone who has ever done something or been successful has had someone who believed in them and made that clear, and helped the student understand how to believe in themselves. I think about that a lot.
Don't be afraid that you don't know enough. I was so afraid that I would get questions I didn't know how to answer. And that's not really what makes you a good teacher. Some of the best teachers I know learned programming at ITP and started teaching programming just a few years after. Because they were so close to the material, they understood how to explain concepts—they remember how it felt not knowing. Something that comes with being afraid when you teach the first time is that you over-prepare, you rush through materials. You're afraid of not teaching enough, so you squeeze every last bit of information into this long lecture. And then you and all the students in the class say, “What the hell was that?” I would say, take your time. Breathe.
That, and maintaining a good balance between talking and doing. It's okay to switch activities a lot and be clear about, “OK, now I'm going to talk, so please put your laptops down. I'm going to explain things. You don't need to copy my code. You just need to look at it. I'll leave the code on the screen, and then in 15 minutes from now open your laptops and let's try to work together.” So you have to be vocal about what you're doing in the classroom. And this mix of lecture and hands-on doing is a style that has worked really well for me.
Well, I continually make the same mistakes over and over again, and one piece of advice I have is to do a lot less than you think you can do. As a long-time neurotic, I am a way over-preparer. For example, I was teaching a new class this semester and I ended up making 30 examples when there was only time to look at like two or three in class. One thing I've often done is to assume that because I made all this stuff, I have to get to it all. Then when there's only ten minutes left of class, I would try to rush through the rest of it. In my opinion, it's definitely much better to slow down and leave stuff out. You can always get to it later, or you can send out an email, or not do it at all.
Obviously, I've been doing a lot with videos [The Coding Train on YouTube] and that's part of an attempt to create an environment where there is some quality of self-paced learning. If you can do this or foster some collaborative learning where the students are working in smaller groups or individually in a kind of workshop setting, it's a really good thing. Much better than rushing through a lecture and showing 500 examples in 15 minutes.
Also, don't overlook teaching students how to ask for help. That's a huge part of the learning process. You can't just teach the programming; you've also got to teach how to get help, like: “How do you ask? What's the right question to ask? When do you write, how do you debug?” All of that type of stuff can easily be lost in the “here's the lesson”-type approach.
I would recommend that first-time educators check out Daniel Shiffman's videos. I love these videos. Some of my students don't like them because they don't think they're serious enough. They think somehow that they shouldn't be having fun learning, which sort of blows my mind. But I think it's seriously important for first-time teachers to witness the enthusiasm that Dan Shiffman has about teaching programming.
I would also recommend doing something similar to what I tell my students to do, which is to look at multiple books to see which book they prefer. Look at as many syllabi as you can find. There's a lot on GitHub. I don't recommend following what someone has done before because I think that teaching should be a creative process; crafting your syllabus should also be a creative process, and you shouldn't just be following someone else's syllabus. However, it's a good way to get assignment ideas and to get to know how certain assignments are just sort of classics.
One thing I do with my students is called “ticket to leave.” Towards the end of class, I give out sticky notes or pieces of paper (but it could be done online). And I tell students to write down three questions that they might have about any of the material that was covered and also to list three key points that they got from what we did in class that day. That way, I can find out what stuck and what the problems were. I think that's a really awesome tool, because then at the beginning of the next class I answer the questions and maybe see something that didn't stick overall. Then I'll go over it again.
I would tell first-time educators to try to teach what they are enthusiastic about, what they actually care about. If the technical aspects matter less than their enthusiasm for the subject, then they shouldn't feel like they have to get up there and lecture about code. It's possible to engage students in lots of different ways. The most important thing is to share what is exciting to you about the practice of programming.
When I started out as a freshman, I really didn't have any kind of interaction with technology whatsoever; in fact, I was probably pretty anti-technology. Then in my first year I took a conceptual art class that included a lot of references to media art, the beginnings of Dada and Fluxus and installation art, and that got me excited about learning some of the tools of new media, which led me into doing some work with sound and video. Then as I started working more with sound in particular, I felt very distant from the medium. Having come from a more materially engaged practice like sculpture and installation, I felt like when I was working with sound I was removed from the material. I was using a software interface but I felt distant from it, so I signed up for an introductory programming class, a Python class. In part, I signed up for it because of the title, which was Thinking with Objects. I liked that because I thought it sounded very physical and visual. Of course, I didn't know it just meant object-oriented code, but luckily the professor was really fascinating—a brilliant, brilliant man who, even in that intro class, started tying the code into ideas about neural networking and genetic algorithms.
Even though we were total beginners and we couldn't quite understand what he was saying, he provided these very visual explanations of neural networks and of organisms and I found that really exciting. Again, I probably would have never continued with it except that he specifically came to me and said, “You should consider taking the Artificial Intelligence class.” If he hadn't gone out of his way to invite me to take this class, I would have thought I wasn't good enough to do it, but because he did I became curious about it, and then I took it and really loved it. This kind of faith in students can make a huge difference. It's what launched me into this whole algorithmic direction.
Teaching a very small group of students, like maybe less than five people, can be really instructive…you get much higher-resolution feedback on how the material is being received. I also think drawing is really helpful. I draw a lot before the class and during the class and I sometimes draw the same thing over and over again. The idea is that I'm performing a drawing and it gives the students the time to think with me about how knowledge is processed. I encourage them to make drawings in their sketchbook as well and then they end up with their own textbook in a way—an explanatory text that they processed themselves.
It's also helpful to understand that not all students are going to appreciate what you teach. If I get twenty percent of the students excited about what I do, I call it a good day. Teaching is a really difficult thing to do.
I really want to emphasize this notion of care, care in a lot of different ways. Care in terms of whether you can create and sustain a motivated and positive space for learning and discussion and for just saying vulnerable stuff like something is not working. Also care for a diverse range of responses, because as a teacher you see some work that is technically strong and some [that shows] the students are struggling—like where they are just changing the values of the parameters. But still they need encouragement, they need appreciation. I think you need to be really sensitive to those students who are unmotivated and falling behind, who have fear and stress. You need to think about how fast you speak, how much repetition you need to have in order to adjust the energy of the classroom.
My advice would be to discourage students from collaborating with peers they know. Try and get people to work in groups where they might be exposed to new ideas or new kinds of things.
The other piece of advice I would give is to be really careful when you start seeing “bro” culture emerge—when you start seeing the classroom segregate and the women are fetching coffee and the guys are doing the code, or where the women are doing all the “art.” Remain very cognizant that it can happen.
In our creative-coding curriculum [at NYU IDM], we have four sections that are all different. I teach one that focuses on music. Allison Parrish teaches one that focuses on text, Kevin Siwoff on graphics and 3D, and Katherine Bennett on physical computing. You choose one to be your home section, but you can float between the others as the classes don't happen simultaneously. You can get reinforcement by going to the other sections….In an ideal world, we would figure out a way to teach all four of those things in each section, and the instructors would rotate, but there's not enough time.
My advice is, don't just make it a graphics class….Teach that first to get it the fuck out of the way and then talk about text, sound, and hardware. Or the Web. Talk about Rest APIs or about all those pet peeves you have about the dot-com fetish of the day. Last year, I had this kid who had hacked his entire home in LA so his mom could hit the snooze button and it would turn on the coffee maker and then when she picked up the coffee [pot], the shower would turn on. Really great stuff! Around that time we'd gotten a beta release of one of those stupid Nest things and I told him to hack it and figure out how to get it to do something useful. Originally, he was like, “I'm going to make a robotic arm for the equipment room,” but by the end of it he had made this weird garden of little automatic bleepy bloopy things that look like bombs. He made this great little art installation out of hacking this piece of horrible commerce tech. That was cool.
I had the pleasure of taking several classes from Marina Zurkow at ITP and she was really mean on the first day of class. She was really strict and she just projected this persona of being very exacting. I found that super refreshing in the context of the rest of ITP, where teachers tend to be a tiny bit lackadaisical. I've tried to adopt Marina's approach at least for that first day: be strict up front and don't give any ground when it comes to the idea that you're the one teaching, and that the class that you've designed or the class that you're teaching is a serious thing that deserves the students’ attention. Otherwise they might not apply themselves to the same degree. It's important they know that you really care and that you're not going to accept work or behavior that doesn't live up to a particular standard, even if you become a super softie as the class evolves. I found that to be successful.