So, today I made my students *step away from the computers*. We went out into the hall for the first 10 minutes of class and introduced ourselves. We all shared our names, where we are from, and what was most difficult about Project 1. The common consensus was that (1) the rounding errors were a problem, because if students rounded too late, then they were getting incorrect answers (fractions of plants in a flowerbed), and (2) not many students know what cubic yards are.
The introductions made a huge impact on morale in the classroom, which was a huge relief for me. The students were all smiling, talking, excited to be working in pairs on the labs. It was such an improvement from last week, and we are going to continue to do small get-to-know-you/icebreaker activities in the following weeks.
The students then started their Lab 2 in pairs. Lab 2 uses Turtle Graphics, which was a huge hit with the intro programming students. The Python package takes the idea of placing a turtle with a pen attached to it on the coordinate plane and then giving it directions for where to move to draw a simple, Microsoft-Paint-style picture.
The lab activity required students to use while and for loops to draw regular polygons. It also required them to prompt the user for input (the number of sides of a polygon to be drawn and the percent additive red/green/blue color that the polygon will be filled) and to check the input for bad values. Surprisingly, the students had the most trouble with checking the input for bad values; they didn’t have any trouble at all with any of the Turtle-related parts of the code. I’m thinking this is the case because Turtle is so *visual*, and it is really obvious when the Turtle turns/draws/changes color unexpectedly. In contrast, inputting bad values into a program can result in intimidating error message output, which students don’t know how to handle or interpret. I wonder how to get them to be less uneasy of the text errors and actually reading that output to look for problems in their code.
For a view of what Turtle looks like, below is an example of the Turtle pictures that students will be expected to make for their Project 2 (due on Monday):
Another classroom dynamic I noticed was the gender interactions. With pair programming, I found that the most effectively communicating pairs were the male/female partners. I didn’t have the chance to observe any female/female pairs because my three female students were all paired with men. Some of the male-male pairs had a lot of tension when I would talk to them about their code; a few even had a hint of competition. It seemed like they were trying not to appear incompetent in front of one another, afraid to voice not understanding a process. On the other hand, the male-female pairs were communicating clearly about whenever one of them was stuck on a particular facet of the lab, and the partner would back up and patiently explain it for them. I’m not sure what to make of this observation, but I did find it interesting. I’m going to continue to pay a bit of attention to it throughout the semester to see how it develops. I’m interested to try pairing two girls together.