Although enrollments in introductory computing courses are rising, many students still struggle to learn programming. Previous research has found that students’ perceptions of the programming process may be one factor that contributes to this problem. Students often assess their own programming abilities overly harshly when experiencing low-level programming moments that are considered normal and expected parts of learning to program. For example, many students think they are doing poorly if they need to stop coding to plan. Research has also shown that students who negatively self-assess in these moments tend to have lower self-efficacy, defined as one’s belief in their ability to achieve a particular outcome. In turn, students with lower self-efficacy tend not to persist in their computing studies. While the criteria that students use to assess their ability have been studied extensively, we have a limited understanding of the origins of these criteria and students’ reasons for adopting them. To address this gap, we conducted a total of 36 interviews with seven introductory computer science students throughout an academic quarter. In each interview, we asked students to think-aloud and explain their reasoning while filling out a self-assessment survey. Through a qualitative analysis of the data, we identified the most common reasons students gave for negatively assessing their performance, including having high expectations for their abilities and feeling like they cannot overcome a struggle. We also identified common reasons why students do not negatively assess their ability in these moments, including believing an experience is “normal” or feeling like they can learn from or overcome a struggle. These findings contribute valuable new knowledge about the underpinnings of students’ self-assessments of ability, and suggest that interventions that explicitly emphasize best practices and normalize struggles in the programming learning process are needed to increase student self-efficacy and persistence in computing.