What's different about teaching artists and designers to code, in contrast with teaching programming in a computer science context?
Educator Leah Buechley has observed that artists and designers are accustomed to (1) learning by making concrete examples, rather than by studying abstract principles; (2) working in ways that are improvisational, rather than planned; and (3) creating things that are expressive, rather than utilitarian. Taken together, Buechley's observations delineate some of the key ways in which the assumptions, cultures, and presumed objectives of traditional computer science education often fail for artists and designers. In this section, educators elaborate on the special conditions and considerations for teaching a “studio art course in computer science.”
I think it's important to teach everyone to code. I think it's a fundamental literacy that we need to be advocating for across the board. But for artists in particular, it has to be project-based. I think that the only way you really get artists motivated is by having them work on their own thing, something that they are actually excited about doing. In my experience, giving a bunch of assignments that they don't care about is kind of useless. Instead, if they are trying to synthesize things that they have read or seen a video about into something that they actually want to make, then they will learn it. I think that's maybe more important than what the project looks like, or what language it is written in, or whether it is something visual or not. At the end of the day, people will want to work on all different kinds of things and I really do think that once they learn one language well, they can just pick up any other one. Really, the aim is to make programming a tool for artists to use of their own volition and with their own agency, to make what they really want to make.
Ultimately people are people, so you can teach classes any number of ways to different groups. However, I think that the idea of sketching with code is really important as it implies a lightness in trying things out. I've had this discussion with Lauren McCarthy, who has a really formal computer science background. She was telling me about how hard it was for her to get used to teaching in a creative context like NYU ITP [the Interactive Telecommunications Program at NYU Tisch] because in computer science, there is this feeling of having to know everything, how everything works and of being able to reproduce everything from scratch in a memorized and almost blue-book test kind of way. In contrast, teaching in a creative environment or in an arts environment is about being able to embrace uncertainty—where students don't necessarily know everything but they should try it anyway, where mistakes might actually lead to exciting ideas, and where there doesn't have to have to be a thing that is solved with an exact answer. In a way, it's almost like stream-of-consciousness coding. I don't want to portray the computer science class in a negative way, but by contrast it's based on learning something exactly and precisely.
To be honest, it's hard for the students. Every semester I have a student say, “Okay, I really feel like I'm not getting this because the thing you showed in class, I can't sit down by myself from a blank sketch and like, write it again.” But nobody can do that, really! Everybody who's programming something is programming it because they did something similar before. Or it's built on top of a library and they started with the example, and that's a totally valid way to learn.
Amongst CS people, I think there is this feeling that the code itself is the art, and that there are all of these ideas and techniques you have to understand first, like managing complexity and modularity, before you can get to really make things. That was really hard for me when I started teaching. I'd think, “Oh, we're just showing the students how to make shapes on the screen; they don't understand what programming is about.” But actually that is totally wrong because programming can be about a lot of different things. Usually when teaching artists, some of them will immediately fall in love with the logic of it, but for a lot of them, that's not why they're excited. Typically they have other goals. If they progress far enough into it, some might start to feel curious about the higher-order stuff of programming, or they may not. As for me, I wasn't interested at all until I realized I could make art with [code], so I think teaching programming to artists is a lot about expanding purist ideas of what programming might be.
I think you need to assume no skill. I think it is really important to make sure that students have the basics right. I think that you also need to review fundamental mathematics in a way that is connected to a visual output. A lot of my students were taught math without it having any meaning; they get taught sine and cosine but they never learned these ideas in terms of animation and oscillation.
Golan Levin: I can relate. Sometimes I have studio art sophomores who don't know the Pythagorean theorem. I'm like, “Here's a right triangle; let's talk about it.” And when they struggle with it I have to remind them, “Folks, c'mon. This is ancient Greek technology. It's the 21st century; you need to know this stuff.”
But it's mathematics, and it's been strangely segmented from the arts. If you identify as a creative person, it's often really hard to see yourself as a mathematician or as a scientist, or that you would even have the confidence to be good at those things, right? So I think you have to really reintroduce subjects in a language the artists understand, which is visual and auditory. And if you can do that, they'll often get it all of a sudden.
I think one of the biggest challenges to respect when teaching artists to code is that this mode of working tends to be pretty solitary. You're in front of a computer screen. It tends to be a time-consuming and solitary experience and that can be frustrating, especially if you're used to practices that are more physical, or group-based, or based on discussion. Instead of talking to people you are talking with a compiler. You're in a conversation mediated through a computer screen, and I notice students who get frustrated with that.
I've actually taught both computer science and art students, because in our digital media department we have both. Computer science students have a totally different mentality from the art/design mindset and one of the reasons why they take our class is because they do want to be “creative.” Of course you can't just typecast them…[but] the ones who might be perceived as more traditional computer science students, they don't consider themselves as being creative or having visual art skills.
I have the class post their projects to OpenProcessing.org, so everybody can see everybody else's work, and a lot of times those students [will] be amazed at what other students came up with, and they realize that their drawings weren't as ambitious. It's really important that they can expand upon it and remix it or whatever you want to call it, as we work with this drawing for a long time. So I give them one week to revise. One of my former coworkers used to say that students rise to the water level that you give them and usually that water level is set by somebody in the class. If one of the students does this amazing thing, then the students look at what they've done and they think, “I can put a little bit more time or effort into this.” I hear a lot of, “I can't draw,” and it's not about that; it's about creative expression and using these basic building blocks like circles, squares, triangles, lines, and points. Yet this actually is sometimes one of the hardest assignments for a lot of the students.
One major difference with teaching designers is that we don't really care about whether the work is done in a “bad” way or if it's implemented in the way engineers would do it. We really just care about making the thing blink, making the thing functional. And then after a long time, the students will learn how to do things properly…but at least when I teach, I'm not that concerned with that in the beginning. In my classes, there is a lot of deconstruction happening that is about technique, but the instruction goes from the artwork backwards to the algorithms and the systems, and finding systems in things that the students normally don't think about as having systems. So we look at graphic designers from the ‘50s and ‘60s, and things like printed posters that were done before the computer. And then try to deconstruct them into, “So this designer sat down and had to do this thing by hand. But how? What was their system”? And then we take that system and then we go backwards, and think, “Okay, how can we do that in code?” So there is a lot of luring the students—like we start with the end goal and then show them the way and the reason why code is important.
From my experience, art and design students have been exposed to artworks in which programming is used in different ways, and so they are not just focused on what works functionally, but are more interested in the thinking behind it. However, programming is still historically and culturally rooted in cultures with high standards of professionalism and instrumentalization; it's seen as a utilitarian skill. When teaching art and design students, I observe that they are very uncomfortable with calling themselves coders or developers. It's like even though you might know how to write, it doesn't mean you would call yourself a “writer.”
What's great about teaching art students or teaching creative writing students is it's rarely vocationally regulated. Nobody is trying to take my class to see if they can get a better job, or very few students are….But it's kind of a relief and a blessing as an instructor to have students who are very eager to learn what I have to say so that they can apply it in their own arts practice. Whenever I say something or whenever I teach them something, you can just see a light go on in their head and they're like, “This is going to let me do this other thing that's a part of my own practice.” It never feels like I have to make the class goal-oriented; it never feels like I have to make the class about working towards something other than our interests as artists. For me, the main difference is that there's a little bit of wiggle room. I can say, “Let's appreciate this process for its aesthetic effect on us,” instead of having to ask, “Does this meet these particular criteria in the curriculum?” or “Is this going to prepare students to succeed in the tech industry?”