Recent work has shown that incarcerated adult students reported a decrease in confidence in their ability to do well in the course as the course progressed, whereas non-incarcerated students in a traditional educational setting reported an increase in confidence over time on the same measure. Given these differences in student experiences between incarcerated adult students and traditional students, this work seeks to further understand the experiences of incarcerated adult in CS1, with a focus on their attitudes towards computing. Specifically, we used the Computing Attitude Survey (CAS) as a pre/post measurement in a CS1 course taught in prison. We found significant positive shifts for Problem Solving - Transfer and Fixed Mindset factors and a slight decrease for Real-World Connections. We additionally compare the results of the CAS survey between the incarcerated adult students in this study and those of non-incarcerated students reported in prior work.

Program comprehension (PC) literature typically focuses on industry professionals comprehending large code bases or novice programmers comprehending short programs. As a result, limited work has aimed to understand how intermediate programmers comprehend large code bases, especially with the goal of supporting learners' incremental development of program comprehension expertise. Through the lens of the Block Model-a theory to support research on and teaching of PC-we aim to uncover 1) the comprehension process that intermediate programmers follow (i.e., top-down, bottom-up, etc.), and 2) common mappings between comprehension techniques used by intermediate programmers and comprehension blocks in the Block Model. We present a diary study of students' “process journals” inwhich they described their PC process while modifying the open-source idlelib code base. Our results showed that students typically followed a top-down and Text-first approach to understand a feature in the idlelib code base. Our findings also reveal how students used various program comprehension techniques (such as code navigation, using the IDE-based debugger, making experimental code changes, etc.) in terms of the Block Model. These findings make progress toward bridging our theoretical understanding of novices' comprehension process in small programs and expert's code comprehension process in large code bases by presenting a high sample size investigation of intermediate programmers' PC processes in a large, existing code base. Instructors can use our findings to understand which blocks in the Block Model are cover PC techniques, which can enable targeted teaching activities to impart PC skills.

Motivation. Trust in generative AI programming assistants is a vital attitude that impacts how programmers use those programming assistants. Programmers that are over-trusting may be too reliant on their tools, leading to incorrect or vulnerable code; programmers that are under-trusting may avoid using tools that can improve their productivity and well-being. Methods. Since trust is a dynamic attitude that may change over time, this study aims to understand programmers' evolution of trust after immediate (one hour) and extended (10 days) use of GitHub Copilot. We collected survey data from 71 upper-division computer science students working on a legacy code base, representing a population that is about to enter the workforce. Leveraging existing survey instruments and open-ended free response questions, we quantitatively measure student trust levels and qualitatively uncover why student trust changes. Findings. Student trust, on average, increased throughout the study. After completing a project with Copilot, however, students felt that Copilot requires a competent programmer to complete some tasks manually. Students mentioned that seeing Copilot's correctness, understanding how Copilot uses context from the code base, and learning some basics of natural language processing contributed to their elevated trust. On the other hand, students pointed to Copilot's incorrect code suggestions as one of their main reasons for having less trust in the tool. Implications. Our study helps instructors and industry managers understand the factors that influence how students calibrate their trust with generative AI programming assistants. We make four pedagogical recommendations, which are that CS educators should 1) provide opportunities for students to work with Copilot on challenging software engineering tasks to calibrate their trust, 2) teach traditional skills of comprehending, debugging, and testing so students can verify output, 3) teach students about the basics of natural language processing, and 4) explicitly introduce and demonstrate the range of features available in Copilot.

Understanding incarcerated adult (IA) students' fears upon entering a CS1 course and how their confidence changes throughout the course can help us understand how well IA students' fears are being addressed, and help future instructors of CS1 in prison address them better. Building on recent work on non-CS majors' fears and confidence in introductory CS, we surveyed 45 IA students across two offerings of a CS1 course in prison on their fears going into the course, and confidence in their ability to succeed. We present a phenomenographic analysis of fears amongst IA students in CS1, and analyze relationships between these fears and change in confidence. In addition, we compare the fears expressed by IA students to those of non-CS majors from prior work. Findings include many IA students reporting no fears, but an overall decrease in confidence across both offerings of the course which was mostly accounted for by students who did express initial fears. We found 9 fears overlapping with those found in a prior study outside of the prison context (e.g., getting a bad grade), and 7 fears only identified in our study (e.g., interference from circumstances beyond my control).

Supplemental resources have particular importance in prison learning contexts, as incarcerated students have less access to course staff and limited ability to seek additional resources themselves (e.g., restricted internet access). In this paper, we examine how students valued paper-based (e.g., textbook) and technology-based (e.g., Canvas discussion board) resources in two iterations of a CS1 course taught in prison. Students in the first iteration did not have access to a code interpreter, while students in the second iteration did. Findings include how students across these two CS1 offerings valued different resources, compared across students' age and comfort with technology.

Large language models (LLMs) are already heavily used by professional software engineers. An important skill for new university graduates to possess will be the ability to use such LLMs to effectively navigate and modify a large code base. While much of the prior work related to LLMs in computing education focuses on novice programmers learning to code, less work has focused on how upper-division students use and trust these tools, especially while working with large code bases. In this study, we taught students about various GitHub Copilot features, including Copilot chat, in an upper-division software engineering course and asked students to add a feature to a large code base using Copilot. Our analysis revealed a novel interaction pattern that we call one-shot prompting, in which students ask Copilot to implement the entire feature at once and spend the next few prompts asking Copilot to debug the code or asking Copilot to regenerate its incorrect response. Finally, students reported significantly more trust in the code comprehension features than code generation features of Copilot, perhaps due to the presence of trust affordances in the Copilot chat that are absent in the code generation features. Our study takes the first steps in understanding how upper-division students use Github Copilot so that our instruction can adequately prepare students for a career in software engineering.

Objectives : The traditional, instructor-led form of live coding has been extensively studied, with findings showing that this form of live coding imparts similar learning to static-code examples. However, a concern with Traditional Live Coding is that it can turn into a passive learning activity for students as they simply observe the instructor program. Therefore, this study compares Active Live Coding—a form of live coding that leverages in-class coding activities and peer discussion—to Traditional Live Coding on three outcomes: (1) students’ adherence to effective programming processes, (2) students’ performance on exams and in-lecture questions, and (3) students’ lecture experience. Participants : Roughly 530 students were enrolled in an advanced, CS1 course taught in Java at a large, public university in North America. The students were primarily first- and second-year undergraduate students with some prior programming experience. The student population was spread across two lecture sections—348 students in the Active Live Coding (ALC) lecture and 185 students in the Traditional Live Coding (TLC) lecture. Study Methods : We used a mixed-methods approach to answer our‘ research questions. To compare students’ programming processes, we applied process-oriented metrics related to incremental development and error frequencies. To measure students’ learning outcomes, we compared students’ performance on major course components and used pre- and post-lecture questionnaires to compare students’ learning gain during lectures. Finally, to understand students’ lecture experience, we used a classroom observation protocol to measure and compare students’ behavioral engagement during the two lectures. We also inductively coded open-ended survey questions to understand students’ perceptions of live coding. Findings : We did not find a statistically significant effect of ALC on students’ programming processes or learning outcomes. It seems that both ALC and TLC impart similar programming processes and result in similar student learning. However, our findings related to students’ lecture experience shows a persistent engagement effect of ALC, where students’ behavioral engagement peaks and remains elevated after the in-class coding activity and peer discussion. Finally, we discuss the unique affordances and drawbacks of the lecture technique as well as students’ perceptions of ALC. Conclusions : Despite being motivated by well-established learning theories, Active Live Coding did not result in improved student learning or programming processes. This study is preceded by several prior works that showed that Traditional Live Coding imparts similar student learning and programming skills as static-code examples. Though potential reasons for the lack of observed learning benefits are discussed in this work, multiple future analyses to further investigate Active Live Coding may help the community understand the impacts (or lack thereof) of the instructional technique.

Background and Context. Prior work has explicitly called on undergraduate computer science (CS) programs to better prepare students for the demands of professional software development. While students in university courses primarily work on programming projects from scratch ("greenfield development") and create small coding projects, professional developers in industry are expected to comprehend and modify large, existing code bases ("brownfield development"). As a result, CS graduates enter the workforce with little to no instruction on how to comprehend and modify a large code base. Objectives. We aim to identify the variety of struggles that final-year undergraduate students experience when comprehending and modifying a large code base so that software engineering instruction can adapt to address students' needs. Methods. We conducted a think-aloud protocol with 13 undergraduates in their final year of a CS degree at a public, four-year university in North America. In the protocol, students modified an existing feature in an open-source code base with roughly 60,000 lines of code. Using Information Foraging Theory to analyze students' code navigation and program comprehension processes, we identified ineffective student behaviors related to their thought processes and comprehension strategies. Findings. We found a variety of ineffective behaviors among students, which we categorized into four concrete struggles. Students were unable to 1) effectively use documentation to get started on the task, 2) use methodical, structurally-guided comprehension processes, 3) find all parts of the relevant code, and 4) abandon irrelevant lines of reasoning. Implications. Our study not only shows that students experience sonic of the same struggles as professional developers, but also identifies struggles that are unique to students with limited experience working on large code bases, such as relying on opportunistic search strategies and over-investigating irrelevant code. We suggest pedagogical recommendations to address these struggles, such as explicitly teaching students about code comprehension techniques for large code bases and designing tasks in which tudents find, comprehend, and modify code across multiple files in a code base.

Live coding is a recommended teaching practice in which an instructor dynamically programs in front of students. However, findings related to students' engagement during live coding are mixed. Some works have reported that live codingseems to improve student engagement while others regard live coding as an activity in which students passively observe the instructor without asking questions or following along. Active live coding, in which students extend a live coding example and discuss with peers, incorporates active learning with the traditional live coding approach. We conducted a quasi-experimental study in which one section of an advanced introductory programming course was taught using active live coding (ALC) and the other was taught using traditional live coding (TLC). The goal of this work is to compare students' behavioral engagement in the two lectures using a classroom observation protocol called the Behavioral Engagement Related to Instruction (BERI) protocol. Our results from the 2,790 observations we collected indicate that traditional live coding engages only 65% of students, on average. However, we found a "persisting engagement'' effect of active live coding, where students were significantlymore engaged in the traditional live coding components of a lecture up to 20 minutesafter the active live coding component. Notably, the two lecture groups performed similarly on the Post-Lecture Questions, which were administered after each lecture as a review of the lecture material. Therefore, our results indicate an improved student engagement due to active live coding, but do not show a corresponding improvement in conceptual knowledge.

Efforts to bring incarcerated and formerly incarcerated individuals into the field of computing stand to improve equitable access to both computing jobs, and consequently the benefits of our tools and innovations through the inclusion of more diverse perspectives. This report describes the design and execution of a college level introductory computing course conducted with 26 students currently incarcerated at a prison in the United States in Fall 2022. We discuss the ways that the prison environment and the student body differ from traditional college computing classes, and how this impacted the design and execution of the course. We found that despite significant environmental barriers to learning to program, such as not having access to a code interpreter, there were unique affordances of the student population, including maturity and community, that could be leveraged in the course design and policies. We conclude with many lessons learned for the purpose of improving future offerings of computing courses in prisons.

Higher education is expanding in United States prisons, with a growing demand for STEM offerings. Academics from other disciplines have stressed the importance of culturally relevant pedagogy (CRP) in prison higher education, and computing in context has shown major benefits in CS1--- especially for women and nontraditional students. More work is needed to determine what contexts are relevant to incarcerated college students, and how to incorporate these into computing curricula. In this paper, we build on prior work on computing in context and culturally relevant techniques in computing. We analyze course data from a CS1 course taught in a college-in-prison program to answer the following research question: What contexts do incarcerated students in CS1 find relevant? We identify 24 topics pursued by students across 78 open-ended programming assignment submissions, the three most popular being business management, sports statistics, and physical health. These results offer insight into potential contexts that are meaningful to incarcerated college students to be incorporated into future computing curricula and interventions in prisons.

Since March of 2020, universities around the world have offered remote versions of courses to help limit the spread of COVID-19. Two years later, in the Spring 2022 quarter, the lectures in the CS1 course at our large, public research-intensive university were taught via two modalities---an in-person modality in which students attended traditional, in-person lectures and a blended modality in which students attended a remote lecture on Zoom. Every other course component---labs, discussions, office hours---were held in-person for both groups. The unique setup of the CS1 course allowed us to perform a comparative analysis of the outcomes and attitudes between the two groups. In this paper, we analyze the difference in course outcomes, peer support, competitive feelings in class, and students' sense of belonging between the groups. Our results indicate that students in the blended learning group attended lectures more frequently than their in-person counterparts yet performed 4-7%worse on the midterm and final exams. The blended learning group also experienced significantlyless feelings of competitiveness than their in-person counterparts. Interestingly, we discovered a consistent trend among our results indicating that the gap in grades, peer support, and classroom competitiveness between the blended group and in-person group was more pronounced among first- and second-year undergraduates than third- and four-year students. Despite the two learning groups having different instructors, our results shed light on the potential advantages and drawbacks of a blended learning experience in CS1 that instructors should consider when deciding on the format of their course.

The US incarcerates more people, and at a higher rate, than any other country in the world---predominantly low-income people of color. Higher education in prison (HEP) has a powerful impact on justice-impacted people, improving their quality of life during incarceration and reducing their likelihood of returning to prison post-release. HEP nearly disappeared in 1994 after Pell Grant eligibility was eliminated for incarcerated students, which was recently reinstated. More computing educators can reach incarcerated students with digital literacy skills, core computing content, and critical analyses of the impacts of computing on society. CS education researchers can also support the growth of CS education in prisons, and influence policies restricting technology infrastructure.

In a large CS class, it's likely that most students will never speak with the instructor. This presents challenges in terms of student engagement. As class time is limited for building rapport, out-of-class interventions are recommended, such as meeting with students in small groups to discuss non-class topics. If an instructor is to meet with all the students, how can the benefits be maximized while mitigating impacts on the instructor's time and students' access to help? What should be discussed? And how beneficial are such meetings, given that they will have to be short? This paper introduces Meet the Professor (MTP), a course element designed with these issues in mind. MTP was deployed in three sections of an upper-division course at UC San Diego. In end-of-course surveys, students broadly reported increases to rapport, most notably finding instructors to be more approachable than they previously thought. Overwhelmingly, students reported appreciation for meeting with the instructor and did not find that MTP interfered with other learning opportunities. Recommendations are provided for managing the instructor's time and maximizing the value of the intervention.

Recent research in computing has shown that student performance on prerequisite course content varies widely, even when students continue to progress further through the computing curriculum. Our work investigates instructors' perspectives on the purpose of prerequisite courses and whether that purpose is being fulfilled. In order to identify the range of instructor views, we interviewed twenty-one computer science instructors, at two institutions, that teach a variety of courses in their respective departments. We conducted a phenomenographic analysis on the interview transcripts, which revealed a wide variety of views on prerequisite courses. The responses shed light on various issues with prerequisite course knowledge, as well as issues around responsibility and conflicting pressures on instructors. These issues arise at the department level, as well as with individual course offerings.

Incremental development is the process of writing a small snippet of code and testing it before moving on. For students in introductory programming courses, the value of incremental development is especially higher as they may suffer from more syntax errors, lack the proficiency to address complicated bugs, and may be more prone to frustration when struggling to correct code. However, to evaluate the effectiveness of interventions that aim to teach programming processes such as incremental development, we need to develop measures to assess such processes. In this paper, we present a way to measure incremental development. By qualitatively analyzing 15 student coding interviews, we identified common behaviors in the programming process that relate to incremental development. We then leveraged a dataset of over 1000 development sessions -- about 52,000 code snapshots at compilation time -- to automatically detect the common behaviors identified in our qualitative analysis. Finally, we crafted a formal metric, called the "Measure of Incremental Development'' (MID), to quantify how effectively a student used incremental development during a programming session. The MID detects common non-incremental development patterns such as excessive debugging after large additions of code to automatically assess a sequence of snapshots. The MID aligns with human evaluations of incrementality with over 80% accuracy. Our metric enables new research directions and interventions focused on improving students' development practices.

Despite the increased importance of Cloud tooling, and many large-scale studies of Cloud users, research has yet to answer what tool modalities (e.g. CLI or web console) developers prefer. In formulating our studies, we quickly found that preference varies heavily based on the programming task at hand. To address this gap, we conducted a two-part research study that quantifies modality preference as a function of programming task. Part one surveys how preference for three tool modalities (CLI, IDE, web console) varies across three classes of task (CRUD, debugging, monitoring). The survey shows, among 60 respondents, developers most prefer the CLI modality, especially for CRUD tasks. Monitoring tasks are the exception for which developers prefer the web console. Part two observes how four participants complete a task using the kubectl CLI and the OpenShift web console. All four participants prefer using the CLI to accomplish the task.