How do you manage novice and experienced students simultaneously?
As programming skills gain wider public adoption, it has become increasingly common to have classes in which experienced and inexperienced programmers are mixed together. This can be particularly vexing in technically oriented contexts, in which the absolute beginners feel lost, while students who are already familiar with the material are bored.
For me, the best way [to manage differing skill levels in a classroom] is to give two different versions of the same assignment, especially for my electronics classes, where there's often different ways of doing the same thing. I like to give challenges to the experienced people who have done it once, and for the beginners, give them enough time to learn. I want to avoid having one person done in ten minutes while there is another person taking an hour to do it. A more hands-on approach we use at SFPC [the School for Poetic Computation] has been to encourage the advanced students to mentor the beginner students—not in a hierarchical way, but to have them solve the problem together. That has mixed success; it works for some assignments and not for others. Something that I learned from other teachers at SFPC is to encourage the more advanced students to build teaching materials. They may be able to solve a problem quickly, but for them to come up with new assignments from that code or new assignments for another toolset is a more conceptual challenge. It's also important to understand that even the most advanced technical students are probably not experienced teachers or artists, and are probably not confident explaining or helping other people, so there's a lot for them to learn from that practice.
For a beginner, I try to have an approach of looking at a particular example in incredible detail—so, line by line, making sure every little piece is sort of talked about and understood, and building up this example. In theory I might do that for half the time and then the other half of the time I look at an example from a higher level, talking about the concepts and demoing it in a way that we can have a more free-form conversation, where it's okay if the students don't suddenly know every part of how the code is working. In some ways I oscillate between shooting for the low end and shooting for the high end, as for me, the place in the middle is sometimes problematic. Like, “I'm kind of showing you the code, but not really” or “I'm just giving you some things but not all of them.” This can get confusing. I feel like it's helpful to either go through the process step by step or to just run an example and talk about what it is and why it's meaningful and important. Then students can look at the code later.
In some ways a lot of what I do is creating a feeling of ease in the classroom. I often joke that I don't know if I'm teaching anybody or if I'm just giving people the feeling that they're learning. Ultimately students have to learn it on their own when they go and try the stuff, and so it's important to have people feel empowered and feel that they can do it.
I teach a class on graphic design and code. What I say in the beginning is, “Some of you are very experienced programmers, but you may not have the experience in the visual arts that some other people have, and that is a skill you will have to acquire. So, it's as hard and as important for you to work on those things. And equally, if you have never programmed before, you might have skills in other places.” So it's not a situation in which students who can already program are considered amazing, but students who are maybe design-driven but have never programmed are regarded as not knowing anything. The other consideration that I have is the pace in the class. I try to never shoot for the lowest common denominator in my class because it does a disservice to all the other students. So I set the bar pretty high. But then in the classroom, I talk a lot about fundamentals that everyone can do. And then if I want, I can be very clear about saying, “Now we're going to talk about something that might be a little hard for some of you. That's completely okay. If you want to, you can play around with this in the meantime, but if you're interested, feel free to follow along.” And then I talk about something that might be a little bit more advanced. Or I'll say, “So everybody practice this now, and I'll go around and help you. If you're really up for a challenge, do this other thing.” So I try to have multiple tiers always going at the same time.
99% of my students are beginners with no programming experience, but after the first few weeks you do start to see who is really into programming, as these students spend hours and hours on it. Then you see different skill levels, so this issue emerges. I alway emphasize that my course is “low floor, high ceiling,” which is discussed by Seymour Papert and Paul Wang in their work on computational thinking. When you introduce programming it has to be with a low barrier; it has to feel accessible so that you can get started. But at the same time it has to feel like there is no limit, no ending, and it's possible to go deeper and deeper. So every assignment I set, even if you are a beginner in terms of coding, you are still able to submit something—with references, with sample code, with tinkering. My assignments aren't computer science assignments where there is a correct answer. Instead, they are conceptual, so that the more advanced students can go really deep and apply more complex programming skills.
Usually what I do is I pull the experienced people aside after class and be like, “Whoa, you're awesome, why don't you go and check out this book. You can ignore me when I talk, if you show me what you can do with this.” I give them stuff that's outside their skillset, that's actually really hard material, and it's like a puzzle and then they sort of ignore you in class, and at the end they come back with something. The other thing you can do is turn them into TAs, but the danger with those students is that their knowledge is usually patchy in that they think they know more than they actually know. I've seen those students become the worst in the class because they get lapped by the others who are paying attention and are systematic in a pedagogical way.
I've learned to not be very rigid in the way that I define projects, and to allow people to operate within those projects at a comfort level that works for them. The first time I taught my class, I defined the projects so rigidly that the difference between the good coders and the bad coders would really stand out, but by defining the projects less rigidly, it allows people to play to their strengths more. That's something that took me a long time to really embrace. My projects are now about a theme and not about how I insist that you work on that theme.
I really try to push that it's not just about wanting to program. A lot of times, if you're a very good programmer, that probably means that you haven't spent a lot of time thinking about art or design or user interaction or any of these things. So I just try to emphasize that, but also when we are giving feedback, I try to call on people who have these other skills to make everyone realize that these are just as important and relevant. Setting expectations in the beginning is helpful. I let the advanced students know that technically [the class] might feel a little bit slow, but that gives them time to explore some of their other ideas. And also vice versa—I try to help the students who are beginners understand that some [of their classmates] have done this before, but [their inexperience] doesn't mean that they are bad at it. I encourage them to not feel intimidated, to survey their skills to see what they are missing, and to ask themselves how they might work on those skills.
I deal with this a lot as most of the classes I teach tend to be mixed…I think having classrooms where there are people with different skill sets is really valuable, specifically in terms of the community. What you want to do is create conversation, create modes in which beginners are asking questions of experts and [there is] a chain of learning. When everyone is in the same place it's much harder to do. What I try to do for the experts is give them prompts where they feel like their input and time in the classroom is both useful and valuable. I often ask them, “Can you take the things that we're talking about and create tools and techniques to teach this better?” I try to turn them into teachers in some way and I try to give them prompts that push them to have that sort of mindset. There are also ways of making everybody a beginner, because everybody is a beginner in something. So in a classroom where there are both beginners and experts, can you figure out ways to push the people who think they know the material and flip what they are doing so that they realize that there is a lot that they don't know? I like to show them the problem set in a different way, like in a different language or with different constraints.
At some point in a bimodal classroom, I also think there is value in pulling out the beginners or the people who feel like they are lost, and creating a safe place where this small subgroup can meet. So in a classroom of 15 you might have 4 or 5 students who meet privately and you try to raise their comfort level and confidence. They often need a safer space to ask questions they might not ask in class because they are shy about asking.
I have to do the “one-room schoolhouse” thing a lot. Sixty percent of my students are products of the New York City public school system because we're NYU's last commuter school and unfortunately, most of my students didn't have the chance to go to Bronx Science or Brooklyn Tech. They went to places where their computing class was maybe how to use Dreamweaver. Some have done CS and they have some math, but nobody ever thought to take them to MoMA or the Guggenheim. One of the things that's really nice about my little proxy for an art program inside an engineering school is that in an engineering school you're encouraged to assign lots of group design work. And so I can figure out these orthogonalities between the students pretty quickly and pair them in ways so that they match each other and so that they have to teach each other stuff. I try to do that as much as possible. It's hard—like this year it's gotten really hard because we started admitting new graduate students coming from other parts of NYU that cover recorded music and undergrad photo. And those kids have a very high cultural fluency, but they don't have any of the computer chops. Or if they do it's like they know how to use a crack of Ableton really well but they don't know how to code. In response, I made every assignment on how to use photography in some way, but everybody had to have a soundtrack. I “de-oculocentrized” the curriculum and everything had to have music, no matter what.
I'm a huge believer in pair-programming, or peer programming. I usually pair a more seasoned programmer with one who is less seasoned or a novice, and I have the novice do the programming and have the more experienced person be the observer. I also encourage the students to form external study groups, as sometimes I find that the students who already have experience programming actually really want to help the other students, and that one of the ways they can do this is by spearheading a study group outside of class. I might also have a student explain a programming concept using different language than what I'm using.
I always tell students to use multiple resources when they learn how to program. I always assign two different textbooks and then tell them to try to get a third resource if they can. They all have different examples and explain certain concepts differently, and I think the more the merrier when they're trying to understand something for the first time.
Tega Brain: You mentioned that you sometimes teach multiple languages in parallel.
I always do. I don't want students thinking “I can only program in X,” because I teach programming as a tool and I want my students to be able to program in any programming environment. If they know what a loop is, or what an array is, or what an object is as a concept, then they just need to figure out the syntax. I teach three programming languages at the same time only because they usually drop one. I don't tell them two is fine but they typically gravitate towards two out of three. I structure the class so that we're learning the basic concepts two-thirds of the way in all three languages, and in the last third of the semester they select their own project. For the week-by-week deliverables they have to write them in all the different languages, and in the final third of the semester they can select one of those languages for the final project. I give them extra credit if they build it in two languages. Mostly they don't like it at first, but I do find that students rise to the water level that you expect of them. Hopefully it helps them learn new languages when they need to, without being afraid.
Teaching technology with the arts in mind kind of gives you a leg up on that problem automatically. If you consider my class as primarily a programming class—which it isn't, but if you look at it from that point of view—it's the conceptual part that levels the students to some extent because there are some students who, despite being beginning programmers, have amazingly strong artistic points of view and are aware of the history of procedural writing or are into conceptual writing in general. Even with the very rudimentary tools that I'm teaching at the beginning, they're able to make something that aesthetically stands up to whatever the advanced programmers are making off the bat. I often teach in Python, and Python used to be a language that not a lot of people knew, and so that was another equalizer for the class. That's been less true more recently in the last couple of years as I get more programmers coming into my class who have a deeper understanding of Python. But then the subject area [of creative writing and computational poetry] helps with that problem. Not a lot of computer programmers know how to do that, so a little bit of every tutorial is going to be new to everyone regardless of what their preexisting programming skill is.