Programming languages tend to contain much more than can fit into a semester or two, and any successful student will keep discovering new details as their work continues. To support this process, I provide study materials covering the basics of each topic, highlighting key terms, and include links to resources for further study. To support students in going farther, I ask them to learn how to use documentation in addition to online tutorials.
An in-person and an online class on the same topic present two different experiences. Studying in person, on campus, offers more extensive interaction with peers and instructor. This context is conducive to group discussion, but requires commuting and class attendance at specific hours. On the other hand, online study provides a learning experience particularly suited for self-starters and telecommuters. This context is conducive to study, self-pacing, and messaging. I teach both kinds of courses using the same readings and assignments; online sections include a discussion forum and short introductory videos.
I strive to honor and include all students. Besides using inclusive language, this means respecting the wishes of those who do and those who don't want to speak in class (Davis, 62–63). In order to support students who prefer either readings or videos, I will assign both, with some overlap between their contents. I am aware that many students have learned English as a second language.
Programming requires constantly translating between natural language and computer language. Our brainstorming, discussion, and comments take place in English, while we implement logic in source code (Deimel, 7). Results are good only when the two are tightly tied — through the careful use of both languages. Therefore, I use functional specifications and problem-based learning (Davis, 217). I state assignment prompts in English and ask students to parse them carefully.
Collaboration in programming can be challenging. Team members interpret and use language differently; they have their own priorities and concerns; and they bring different insights to the same problem (Davis, 63–64). This natural variation provides an opportunity to poll and learn from the diversity of our community of practice. For this reason I use short problem prompts that leave a bit of room for interpretation.
To succeed in a collaborative environment, we must learn to incorporate each other's perspectives and to help each other reach consensus (Davis, 191; Deimel, 5). It is essential that programs be read as well as executed (Abelson et al., xxiv). Therefore, I ask students to peer review the code and functionality of each other's work (Davis, 310–311). The reviews provide a view of the various qualities of a program that is more comprehensive than one I could provide by myself, and challenge students to comprehend the different ways that their peers tackle the same problem. To keep reviews honest, they are anonymous; to keep them productive and respectful, I personally remove any problematic ones.
Whether a program is “correct” and adheres to norms are matters of degree and judgment. Aside from whether a program causes errors, we are also interested in aspects such as how completely it resolves the problem in the assignment prompt; how clearly it is written; how simply it operates; and how well it is documented. I ask students to review programs holistically, combining these factors into the rubric “clarity and correctness.”
I measure student progress based on participation in the submission–review cycle, with extra credit available for extra reviews. I forgive a fraction of the deliverables, which gives students leeway to handle extracurricular circumstances. This approach is an example of minimal grading and contract grading (Stommel, unpaginated).
Unavoidably, students' computers will also be a little different from each other. Many different software interfaces and environments are suitable for programming, and for this reason, where to click and the name of a needed option is different for many of us. For those who need to choose an editor or a terminal program, I will offer the best advice I can. Some prefer relatively minimalist or maximalist setups; neither is more correct nor more appropriate.
Technical requirements mean technical problems, and students cannot expect to solve every hangup without asking for help. Therefore, every course has group discussion in a classroom or an online forum, and I ask students to contact me personally if and when they wish to discuss a problem away from their peers. It is normal for instructors in technical fields to provide tech support to their students (McClurken and Boggs, 82–83).
Adopting a standard reference platform guarantees that our programs perform consistently for each other. The dominant operating systems used for Computer Science instruction are versions of UNIX, often Linux (Doyle and Lister, 4). The College operates a student development server which is our common environment. Although students wholly new to UNIX can find this transition challenging, a week of ramping up is enough to log into the system and run programs there (Kendon and Stephenson, 1–2).
The policies for my courses are listed all together. For any questions, please write to me at abrick@ccsf.edu.
Abelson et al. Structure and Interpretation of Computer Programs (MIT, 2022).
Davis, Barbara. Tools for Teaching (Jossey-Bass, 2009).
Deimel, Jr., Lionel E. “The Uses of Program Reading”, in SIGCSE Bulletin (ACM, 1985).
Doyle and Lister. “Why Teach Unix?,” at Ninth Australasian Computing Education Conference (Australian Computer Society, 2007).
Kendon and Stephenson. “Unix Literacy for First-Year Computer Science Students,” in Proceedings of the 21st Western Canadian Conference on Computing Education (ACM, 2016).
McClurken, Boggs, et al. “Digital Literacy and the Undergraduate Curriculum,” in Hacking the Academy: New Approaches to Scholarship and Teaching from Digital Humanities (Michigan, 2013).
Stommel, Jesse. “Ungrading: an Introduction” (jessestommel.com, 2021).