“Screens Down!” (The Ecosystem of the Computer Science Classroom)

As a computer science student, I confess that it’s hard to focus when your primary tool for productivity is also connected wirelessly to an infinite bank of distractions. And I’m supposed to be disciplined.

Controlling/Directing/Supervising/Babysitting/Commanding (etc) a classroom of dozens of students with varying interest levels is tricky. Having computers makes it that much more… impossible?

The introduction of the computer into the classroom environment changes things. So I’ll put on my anthropologist hat and observe and report on this environment:

Solo Coding: I’ll get started as soon as youtube/ pandora/ Soundcloud starts playing

This is the most traditional environment for a programmer and is a default choice in the classroom. Here, students are not instructed to work with anyone in particular and there is (supposed to be) a 1:1 ratio of students to computers. Students typically self-assemble into “herds” (some prefer to work alone) and find their earbuds and the latest Taylor Swift, Kap Slap, Kanye, etc. mix and begin to program…eventually.

Getting students into their coding rhythm is the challenge. In a fifty minute period, students will typically get in their zone in five to twenty minutes. To reiterate, nothing happens until they sit with their friends and begin chatting and then put headphones on (and chat louder). But eventually things settle down and the music fuels the code. It just takes longer than teachers would prefer.

Pair Programming: The wheelbarrow race of programming

In pair programming there is a pair of students to each computer. These pairs are typically self-selected. In its purest sense, pair programming involves two roles: Navigator and Driver. The navigator decides in which direction the code will go, making design decisions and telling the driver what to do. He is not actually supposed to touch a keyboard or mouse. The driver operates the keyboard and mouse and actually produces the code as instructed by the navigator. The navigator and driver switch roles periodically.

To be fair, no one follows pair programming to the “T”, and Ms. Serene’s class is no exception. The roles of pairs are across the spectrum. Some pairs ignore the roles and pass/take the keyboard to the member who has an idea. Other pairs take the “navigator” role as a good time to check in with other groups and friends. Other pairs never switch roles because one of them is disengaged and not really contributing, so one person is trying to hold the map and drive (serves both roles).

Despite all this, I am a fan of pair programming. It needs a little bit of guidance (especially in the beginning), but it encourages students to either think or do, either to design or code, but not both at the same time. Any introduction to the concept of designing is crucial to computer science education.

And pair programming gets them to play well with others. Always a plus.

Screens Down (to at least an acute angle)

This is the hardest part of the day for most students. “Screens Down” involves students looking up from the screen and focusing on another human being (their teacher to be specific).

When Ms. Serene or Ms. Song requires the entire classes’ attention (typically to wrap up a class or make an announcement), they ask for screens down (for laptops) or screens off (for computers). You have to remove the screen from play because there is no way a teacher can compete with the magical box of infinite distractions.

It usually takes anywhere from thirty seconds to a minute or two to get all screens down/off. There is always a few rebellious students who try to “subtly” work in their almost but not quite closed screens. But if a teacher requires attention from the entire class, you need to remove the screen.

---

When you’re teaching computer science, prepare to compete with the machine for attention. It plays music and is connected to the internet. You’re not. Play to your strengths and remember to command it to turn off when you need it to.

“As Long as I get Credit” (Grading Computer Science)

Grading a math assignment is trivial. Right is right, wrong is wrong. (Ok, so there is also something to be said about showing work and partial credit.)

Grading an english paper is a bit more challenging. Proper grammar is one thing, but the logic, style, and the flow of the paper is less objective and more up to interpretation. And don’t get me started on grading art, because I’m an engineer.

Case and point: If it involves creativity, it’s hard to grade.

So how do you grade computer science?

So sure, it’s one thing to grade purely functional code. That’s like a math assignment. Does this code do this thing? We can grade that with automated testing. In my software engineering course I took sophomore year of college, everything was automatically graded through unit testing. Does my code successfully find the greatest common factor? Did I consider edge cases such as negative numbers, zero, or even words as input? Yes or no. Black or white. But that’s functional code. That’s not the issue at hand.

Taking a step back, we have to consider programming projects that are a bit more elementary, that invoke a greater sense of creativity. This is the challenge that Ms. Serene and Ms. Song face in their classroom, that countless middle school, high school, and college educators face when they teach introduction computer science courses. These courses involve projects that require creativity to engage budding CS students in programming. Put simply, a talent show featuring dancing animals is more comfortable to program than finding the nth fibonacci number in linear time.

Both Ms. Song and Ms. Serene award points for progression in the form of daily check-ins. Ms. Song checks students off every other day or so to ensure they are making progress. Ms. Serene has students submit their work at the end of each day so that she can review it. So it is clear that consistent progress is important in both classrooms. And reflecting on my own coding projects, many of which lay dormant until the deadline looms, I feel that these checkpoints are crucial to instilling good habits in programming, or really problem solving in general.

Here’s the big secret in Ms. Serene’s class:

Everyone gets an A

(so long as they meet the basic requirements, so long as they “finish” the project/assignment)

Crazy right? So let’s think about this. On one hand, students shrug of the pressure of having to get it “perfect” in favor of taking risks and making mistakes in a safe environment. On the other hand, students (especially the high achieving but perhaps less motivated ones) are overheard saying things such as:

“On stupid stuff like this, I don’t need to do something memorable. Especially when I can just get ahead” -student

When you set a clear threshold, it’s inevitable to find that almost every student finds his way just past over it and not much further.

So how do you create a minimum threshold while also encouraging students to reach higher?

It’s an open-ended and certainly important question. The solution can’t be easily summarized in a blog, but it will involve open-ended projects with a sense of purpose. If projects are open-ended, they will inevitably differ and align with student’s previous experiences and interests, so it has a purpose and isn’t “stupid.”

Students should be able to show off their project and have a sense of ownership over what they have done. So a bit of competition/bragging in the classroom come project time is probably a good thing. Just make sure the incremental progress is being monitored as well.