A report from the Summer 2017 CS Department workshop

Yup, that’s right. I was in two workshops last week. One was a workshop on letterpress. The other was the CS department’s workshop. In the former case, I was a participant in the workshop. In the latter, I ran the workshop. And so I am writing the summary of the workshop for those who funded it [1].

From: Samuel A. Rebelsky
To: Our wonderful funders
Re: Report on Summer 2017 CS Department Workshop
7 August 2017
 

We very much appreciate your support for the CS department workshop of 31 July to 4 August 2017. This report summarizes the discussions, conclusions, and plans from that workshop.

We had five primary goals for the workshop: To consider issues related to the experience of second-year students in the department, to consider exit interviews with our seniors, to begin planning for our self study and decennial review in 2018-19, to explore ways to address the effects of our significant enrollment pressures, and to consider issues of inclusion in the department. As is often the case, these goals intersect in many ways, for example, exit interviews tell us about the experiences of students, and questions about the second-year student experience are likely to be important in our review. We also had a number of lesser, also interrelated goals, that we considered as part of the workshop. I report on them in the sections below. I can also provide more detailed notes for each day of the workshop, if you would prefer.

As part of the workshop, we reviewed the following documents:

• The reviewers’ report from our last external review.
• The department’s response to that report.
• Approximately fifty exit interviews from 2016 and 2017.
• The department’s student learning goals.
• The department’s curriculum description.
• The College’s guidelines and template for external reviews.
• Historical enrollment data.
• Budget data, including individual spending on peer educators (mentors, evening tutors, individual tutors, and graders).
• A document prepared by Jerod Weinman that models faculty needs based on major requirements and historical trends (e.g., about 1/3 of students who take CSC 151 become CS majors).
• Portions of ACM/IEEE 2013 Computing Curricula, our professional societies’ guidelines for undergraduate programs in computer science. (We are one of the exemplar programs listed in those guidelines, but we still find it valuable to review them.)
• A reading on pair programming and Jerod Weinman’s notes to his students on pair programming.
• A variety of other notes and class handouts.

Our agenda was necessarily malleable. We adjusted topics and length as we went, as investigations of one area often raised new issues or complexities.

Summaries of Selected Discussions

Introductory sequence

We spent a significant amount of time on the second and third courses in the major, CSC 161, Imperative Problem Solving and Data Structures and CSC 207, Object-Oriented Problem Solving and Algorithms. These are the two primary gateway courses to the major. Most majors take CSC 207 in their second year. About one-third of majors take CSC 161 in their second year.

We entered the workshop with some concerns about the transitions between CSC 161 and CSC 207, between CSC 207 and CSC 301, our upper-level course in Algorithms, and between CSC 161 and CSC 211 and CSC 213, our mid-level courses on systems. Considering those transitions was a focus of our discussion, which required close discussion not only of what is taught in each course, but also what subsequent courses expect from prior courses.

Our discussions led to two primary conclusions. First, we realized that most of what we expect from each course in subsequent courses is covered in the prerequisite courses. The issue seems to be more that students need a bit more reinforcement of their learning. We should also ramp up the difficulty in CSC 301, since the transition issues from CSC 207 to CSC 301 seems to be that the common material in those two courses is sometimes covered at the same level. Second, we decided to include a unit on graphs in CSC 207 in addition to CSC 301. We have generally counted on MAT 218 to cover graphs, but the new model for MAT 218 means that they are not necessarily covered. We have always covered them in CSC 301, but usually expect some basic knowledge.

I will note that our review of exit interviews suggests that our introductory sequence is already quite strong; many graduates identified it as a highlight of our curriculum.

Pair programming

One of the strengths of our introductory sequence is that we regularly rely on pair programming in those courses. Pair programming is a practice in which two programmers work together on problems. Most typically, one takes the role of driver, the partner takes the lead in coming up with solutions or ideas, and the other takes the role of navigator, someone providing feedback and guidance. We regularly switch roles, either during class or between classes. We also regularly switch pairs, so that students have an experience of working with a variety of different students. Although pair programming is a professional practice, we employ it primarily to organize learning, rather than to develop programming skills.

There are many values to the use of pair programming in our curriculum. Here are some. It builds students’ ability to work with others. It makes students more productive, because it really is the case that two heads are better than one. It regularly exposes students to other ways of thinking. It helps build community in the department. It exposes them to an important professional practice.

Unfortunately, pair programming is associated with some of the difficulties in our department. Some students, particularly early in their careers, do not treat their partners with appropriate respect. This issue most significantly affects students traditionally underrepresented in the discipline. Interestingly, the issue seems to be more pronounced in CSC 161, the second course, rather than CSC 151, the first course.

Those experiences, along with some notes from exit interviews which, while largely positive about pair programming, raise some similar issues, suggest that we need to revisit how we present and conduct our pair programming work.

We did observe from both exit interviews and our own experiences that, while there are flaws in our pair programming process, that process does build a sense of respect between students and an understanding of appropriate behavior that we can rely on in the upper-level classes. Hence, some of our discussion addressed the issue of students who place out of the introductory sequence and therefore lack the behavioral growth that happens in the introductory sequence.

Our primary conclusions were that we need to be a bit more intentional about describing and enforcing pair programming practices not just in CSC 151, but also in CSC 161, CSC 207, CSC 211, and CSC 213. In addition, we plan to post a poster summary of good pair programming practices in our primary computing classrooms; those posters should be in place by the beginning of the semester. One of us plans to try Pair Contracts in their class. One plans to have students read aloud statements from prior students about their experiences, both positive and negative, with pair programming.

The role of mathematics in CS

Computer science is a mathematical discipline. In recent years, we have changed our mathematics requirement from MAT 218, which also required MAT 215, MAT 133, and MAT 131, to MAT 218 or the new MAT/CSC 208, Discrete Structures, along with one other course in Mathematics or Statistics numbered over 131. The primary rationales for the change were to reduce the burden on CS majors and to provide more flexibility because Statistics can be as valuable to some CS majors as Calculus II and Linear Algebra.

However, the change has had an impact on the more mathematical upper-level courses. We have a dichotomy between students with strong mathematical skills who feel that the courses are insufficiently mathematical and the students with weaker mathematical skills feel overly challenged by those courses.

We did not come up with any solutions to this issue. There is some hope that we can tune the curriculum of MAT/CSC 208 to help address the differences. I expect that this is one issue that we will return to as part of the self-study and external review.

Handling enrollment pressures

As you may know, the department is dealing with significant enrollment pressures. We have gone from 13 majors in the class of 2015 to 51 in the class of 2019. With the Trustees and President having placed a cap on the number of tenure-line faculty at the College, we need to be more creative in how we address this problem.

Jerod developed a variety of mathematical models to explore the number of majors we can handle with our current number of faculty and the number of faculty needed for different numbers of majors. I can provide those to you separately if you’d like.

Our exit interviews suggest that our students are also worried about these pressures and their effects on not only the strong sense of community within the department, but also the wellness of their faculty.

The department also considered a number of approaches to take if we cannot obtain sufficient resources. I find all of them unacceptable, but they may nontheless be necessary. We anticipate discussing those with the Dean and, possibly, with the President.

Additional issues raised in discussions and exit interviews

We noted that many of our students, particularly those from underrepresented groups, suffer from imposter syndrome. We are considering ways to address this issues.

The most common theme on the exit interviews was the role of CSC321/22, our upper-level software design courses. Students saw potential value in the courses (and some indicated that they were among the most valuable courses), but many objected to the model of the course, which emphasizes You get out of this course what you put into the course, rather than regular formal feedback. Those teaching the course will explore ways to provide that feedback as a check on the student work.

Students found attendance at the Richard Tapia Celebration of Diversity in Computing and the Grace Hopper Celebration of Women in Computing. Our HHMI grant has helped many students experience these opportunities and we will need to find other mechanisms for support.

Our peer education program is working quite well. Students report benefits from both being and having peer educators. Our new Peer-Education Coordinator is making the program even better.

While ethics plays a clear role in our curriculum, we should explore ways to give it an even more central role.

Students would like more chances for professional development, such as mock interviews and opportunities to meet with alumni. Some spoke particularly positively about the career fair associated with the CS Reunion.

Selected plans and outcomes

Plans already implemented or soon to be implemented

• Add a unit on graphs to CSC 207. This change will begin this fall. We will need to adapt CSC 301, Algorithm Analysis, to accommodate not only this change, but the differences in student background it implies for the next few years.
• Remove the unit on program correctness from CSC 207 to make room for the unit on graphs. Add it to CSC 301.
• Develop additional curricular materials to support pair programming.
• Add more formal review of student work in CSC 321/22.

Relatively straightforward tasks

• Rename CSC 161 to Imperative Problem Solving and Memory Management.
• Rename CSC 207 to Object-Oriented Problem Solving, Data Structures, and Algorithms.
• Change the prerequisites of CSC 341 to require CSC 207 rather than CSC 161.
• Create a poster to address issues of imposter syndrome.

Additional plans

• Work with the SEPC to support/enhance the sense of community in the department. More regular notices of community events, such as weekly study breaks is one easy approach. Re-starting our CS Buddies program, which pairs upper-level students with first-years, will take more effort.
• Work with students to create more community activities. These include student-run sessions for programming challenges, student-run reading groups, and outreach activities (e.g., the Drake Library Code Clubs).
• Revisit prerequisites for other upper-level courses.
• Revisit our learning goals for majors.
• Further explore whether mathematics should be one of the core issues for our external review.
• Work with the Dean and President to ensure that we have sufficient resources to support our students, both majors and non-majors, and to identify what approaches to take if we don’t.
• Seek additional support for bringing students to Tapia and GHC.
• Work with CLS on professional development opportunities for our students.

Final thoughts

Thank you once again for your support of this workshop. The department had useful and, in many cases essential, discussions throughout the workshop. I expect that it will have a significant impact on our department.

[1] We would have held the workshop whether or not we got funding. But it was nice to have a lunch together and some snacks and a bit of a stipend.

Version 1.0 of 2017-08-07.