Step 54: Review CS1 Goals (Part 4)

This is the last post in this series of reflection about teaching CS1. For the last couple weeks, I have written about my goals for the course and what I did (deliberately or not) to meet those goals. Today I will be addressing changes for future iterations of the course.

Let me start with two particular goals I would like to improve on. One is the encouragement of test-driven development. Although students proved capable of writing good tests for highly visual problems, there is room for improvement in developing their general testcase writing skills. The simple way to do this is to increase the use of peer-submitted testcases, introducing them earlier and requiring students to submit testcases more often. (Several assignments in the later half of the semester allowed for significant creativity for the students, such as creating a picture of their choice, which could not be easily autograded.)

The obstacle here is mostly in logistics, as I don’t want to impose deadlines for the testcases in addition to the actual assignment. What I might do is only allow students to use their own test cases to begin with – essentially turning the autograder into a single-user testing platform – then do a batch regrade afterwards. This requires slightly more work on my part, but should help students build the testing habit. I am also considering making students reflect on the coverage of their testcases, but that may be too much.

The second goal I would like to work towards is functional decomposition. This was not something I explicitly addressed this semester, which is an oversight I intend to fix. More generally though, I suspect a greater focus on the design and structure of programs will help. For now, my plan is to require pair programming during the labs; since students are already working in pairs (but each with their own laptop), this is a relatively small change. I’m also thinking that students must be able to explain how their code will work to me (at first) and to each other (later) before actually coding.

There are other changes as well. The most general one is, as has been apparent on this blog, that I badly over-estimated what students were capable of. I think the root cause of this is that I had too rosy a view of CS1 at Michigan. It’s only now that I can see how I may have been blinded by my positive experience teaching the course and not realized that students may not have learned as much as I thought. The pedagogical content knowledge I gained this semester will be used to tweak everything next time.

The remaining changes all come from the teaching evaluations. The first is changing how I teach multiple programming languages. This semester, we spent the majority of the course on Python, then two weeks (and a lab and a homework) on Java. This was not well received:

I think the last few classes spend on Java & Javascript were unhelpful and could have been made more effective by focusing more on classes and more Python/HTML related topics. I think the web app would be better off being focused more towards the last couple weeks instead of just cramming it in (which is what it felt like). Java and Javascript were not smart uses of our time (in my opinion).

The intention was to prepare students for the next course (which is in Java), and also to blur the trees (syntax) to see the forest (the computational ideas). While using multiple languages is not uncommon, I don’t know of any literature on how/when to present the second languages. Introducing every concept in Python first was the obvious first approach, but next time I might introduce OOP in Java, then later reintroduce the same concepts in Python. Since OOP is right after spring break, this might help reinforce the old concepts (branches, loops) while forcing students to engage with Java. The JavaScript, on the other hand, I might remove from the syllabus entirely.

The last major improvement to make is about the ability for individual students to do work. I mentioned that the students work in pairs during lab; they also work in groups for their large projects, leaving just their homework which is done independently. This organization is good for enthusiasm…

This class was overall a good experience for me. It really helped that group work was encouraged so much, and I loved having the work sessions in the library.

…but perhaps not so good for confidence:

I am ending this class feeling pretty dependent on others to help with my programming, so if there was a way to make the class slightly more independent, I think that could be good.

I know programming is a collaborative effort, but it often times feels like the only way I can complete an assignment is with help from my peers or the professor. Perhaps we are allowed to collaborate too much, which leaves us reliant on our peers.

I don’t have a good general solution, although several students suggested that I hold individual check-ins every few weeks, which I think is a great idea. This would also help mitigate the mixed skill levels of students, something I’ve already noticed, while also encouraging a more diverse group of students to continue in computer science.

The devil is in the details of all of these changes, of course, but I’m making the plans now and will see how they work in the fall.

Step 54: Review CS1 Goals (Part 4)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s