As we're getting close to wrapping up this semester's offering of Software Carpentry, we've been putting some thought into the things that worked and didn't work in terms of how we administered the course. Here's what we came up with:
What Worked Well
Version Control — Students really seemed to recognize the value of incorporating version control into their work practices. Of all the topics covered so far, we've received the most positive feedback about version control.
Midterm Quiz — This was useful for assessing the students' learning, and getting an idea of how many of the students were keeping up with the material.
Check-ins — About a month ago, we had each of the students meet with us on Skype for 10 minutes or so. Again, this helped us get an idea of how the students were doing with the course material, and also allowed the students to give us feedback on things they'd like to see changed/added to SWC.
TA Organization — Although we got off to a bit of a slow start, the Software Carpentry TAs managed to get organized in terms of the administrative aspects of the course. Division of labor, and explicitly assigning tasks to specific people seemed to work well.
Asking Students for their Problems — We spoke to a few students about the kinds of computer-related problems they are facing in their research. Next semester we hope to write weekly blog posts in which we will work through the solutions to the problems that the students are reporting.
They like us! — The feedback we've been getting from students indicates that they are enjoying the SWC course, and see the value of the material.
What Went Wrong
Silent Running — With the exception of the midterm quiz and check-ins, we were in the dark about how the students were doing, and whether or not they were keeping up with the lectures. There also wasn't much conversation among the students, or between the students and TAs.
Prerequisites — The Software Carpentry course assumes that students have had some basic programming experience. We were not clear enough (or firm enough) about this. Greg Wilson, the course organizer, wrote a separate post about this.
Initial Organization — Getting things running at the beginning of term took some time, and we weren't very successful at communicating to the students what they should be working on each week.
Pacing — This term's lecture schedule was uneven. The first three topics (version control, spreadsheets, and databases) are very light compared to the fast-paced Python lecture series that follows. It appears that many students may have fallen behind at this point (but that may also have something to do with other coursework and deadlines). Perhaps the Python lectures assumed a higher level of prior programming experience than the first three lectures, and we saw a drop off because we had not fully expressed what the prerequisites were.
The Second Check-in — Since the initial check-ins went so well, we decided to do them again this week. This time, very few students have taken the time to speak with us. Perhaps this was too soon to be asking for a second meeting, or we were encroaching on other courses' exams and projects.
Exercises — We were late in creating the exercises for many of the lecture topics. Also, the style of the exercises is inconsistent, and we do not have solutions posted for some of them.
Office Hours — Office hours were not well attended. In general, the only time that students signed up for office hours was when we specifically requested that they check in with us.
Anything we missed? Current students: please help us out by leaving some comments! Thanks.
Originally posted 2010-12-02 by Ainsley Lawson in Assessment.