Situating Computing Students’ Self-Assessments of Ability in a Collaborative Programming Context
TL;DR
These preliminary findings demonstrate collaborative programming moments that were meaningful from students’ perspectives and how students’ self-assessments are contextually situated, and the criteria students hold for good programming are situated in contexts that render certain practices more or less acceptable.
Abstract
Research shows students’ beliefs about programming ability can lead them to view routine programming moments, like looking up syntax, as signs of poor performance [3]. These beliefs arise from many sources, including professors, peers, and professionals, and inform students’ self-assessments of ability [2]. While these beliefs are socially and culturally shaped, they have not yet been studied in collaborative programming contexts. As collaborative programming is commonplace in computer science (CS) courses [4, 5], we ask: (RQ1) At what moments do students self-assess their ability while collaboratively programming? and (RQ2) What contextual details do students reference when explaining their self-assessments? We conducted a lab and interview study with 12 introductory CS students. Randomly assigned pairs completed a 5-minute warm-up and a 40-minute task. Then, each student was individually interviewed about their task experience, criteria for determining if someone is a good programmer, and prior CS experiences. Students also drew and explained graphs of their confidence in their programming ability during the lab study (see Figure 1). The authors inductively coded the interviews over two rounds. Figure 1: Student-drawn graphs of confidence in programming ability. Partners interpreted the same experience differently. Addressing RQ1, we found overlaps with the 14 self-assessment criteria Gorson and O’Rourke elicited from students programming by themselves [3]. We also contribute new criteria: generates ideas, understands concepts, seeks help, confidence, looks impressive, knows many languages, and collaborates well. We hypothesize these new criteria arose because the collaborative context attuned students to more prosocial programming practices. We further argue the proliferation of generative AI informed these criteria. For example, one participant explained having “an idea in your head” was more important than being able to execute it, since, “in the future… who knows what’s going to happen with vibe coding.” For RQ2, we found that the criteria students hold for good programming are situated in contexts that render certain practices more or less acceptable. Namely, students attended to environmental details like problem difficulty, problem presentation, and available tools to determine acceptable programming practice. Students also drew upon social cues through peer comparison and understandings of social responsibility, which strengthened certain criteria. Students’ interpretations of these contexts were informed by their accumulated experiences across environments that amplified or dampened impacts of given moments on their self-assessments. As a participant explained: “if I have the preexisting belief that recursion is hard for me and I got another piece of proof… [my confidence] is going to take a hit… even if I try resisting it.” Our preliminary findings demonstrate collaborative programming moments that were meaningful from students’ perspectives and how students’ self-assessments are contextually situated. Building with the theory of learning ecologies [1], we locate competence outside individual programmers, enriching our understanding of self-assessments as contextualized across encounters with programming environments with particular affordances and limitations. Course designers could support students’ confidence by presenting problems in ways that align with desired outcomes, modeling multiple ways students can contribute when collaboratively programming, and addressing messages about programming students carry in from other environments.