Purpose-First Programming

Purpose-first Programming: A Programming Learning Approach for Learners Who Care Most About What Code Achieves by Kathryn Irene Cunningham A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Information) in The University of Michigan 2021 Doctoral Committee: Assistant Professor Barbara Ericson, Co-Chair Professor Mark Guzdial, Co-Chair Associate Professor Chris Quintana Research Professor Stephanie Teasley Smilodon californicus and Canis dirus fight over a Mammuthus columbi carcass in the La Brea Tar Pits. Artist: Robert Bruce Horsfall Source: William Berryman Scott, A history of land mammals in the western hemi- sphere, New York, MacMillan Publishing Company, 1913. Frontispiece. Kathryn Irene Cunningham [email protected] ORCID iD: 0000-0002-9702-2796 c Kathryn Irene Cunningham 2021 ACKNOWLEDGEMENTS I have been very fortunate to work on my doctorate with support from my research community, my friends, and my family. Thanks to everyone who encouraged me to write this thesis, and who helped me see it through to the end. Mark Guzdial and Barbara Ericson provided invaluable guidance and knowl- edge as they advised me through my doctorate and into the next step in my career. I am so grateful for not only their support for my research, but also their emotional support as I weathered the challenges of moving from Georgia Tech to Michigan. Many times, my peers were my greatest motivators. My classmates at Geor- gia Tech encouraged me to live up to their example as rock star researchers, and the community of computing education graduate students constantly renewed my passion for our field. The undergraduate researchers I’ve worked with likely didn’t know how help- ful their excitement and enthusiasm was to my progress. My former students at Hartnell Community College and California State Monterey Bay are often in my thoughts, and I thank them for reminding me about the life-changing impact of quality computer science education. My friends have been there for me when I needed it most, with encouraging words, letters, and video calls. Special thanks to Rebecca Krosnick for understanding both my love of baseball and the struggle of maintaining self-confidence in graduate school, and to Eshwar Chandrasekharan for his listening ear, kind words, and strength. ii Thanks to my parents and my brother for their endless support and love. Thanks to the National Science foundation for funding my research and having confidence in my future as a researcher. This material is based upon work sup- ported by the National Science Foundation Graduate Research Fellowship under Grant No. DGE 1256260. iii TABLE OF CONTENTS ACKNOWLEDGEMENTS :::::::::::::::::::::::::::: ii LIST OF FIGURES :::::::::::::::::::::::::::::::: ix LIST OF TABLES ::::::::::::::::::::::::::::::::: xi ABSTRACT :::::::::::::::::::::::::::::::::::: xii CHAPTER I. Overview of the Thesis ..........................1 1.1 Background: Code’s structure, behavior, and function....2 1.2 Understanding the challenge: Why novices avoid code tracing4 1.2.1 Novice rationales for sketching and tracing, and how they try to avoid it................4 1.2.2 “I’m not a computer”: How identity informs value and expectancy during a programming activity..6 1.3 Meeting the challenge: Purpose-first programming......7 1.3.1 How it’s designed...................8 1.3.2 Why it might work...................8 1.3.3 How I evaluated it and what I found.........8 1.4 Implications for programming learning.............9 II. Using the Structure Behavior Function Framework to Understand Programming Learning .......................... 11 2.1 The Structure Behavior Function framework.......... 12 2.1.1 What is the Structure Behavior Function framework? 12 2.1.2 How do structure, behavior, and function interact? 13 2.1.3 Where did SBF originate?............... 14 2.1.4 What do we know about SBF in learning environ- ments?.......................... 18 iv 2.2 What are Structure, Function, and Behavior in the context of programming?........................... 20 2.2.1 Structure of a program................. 20 2.2.2 Behavior of a program................. 24 2.2.3 Function of a program................. 27 2.2.4 Connections between structure, function, and behavior........................... 29 2.3 Three theories of programming instruction through an SBF lens................................. 31 2.3.1 The “Neo-Piagetian” hierarchy of programming skills .............................. 31 2.3.2 Xie et al.’s theory of programming instruction... 33 2.3.3 Schulte’s Block Model................. 37 2.3.4 Discussion........................ 40 2.4 Conclusion............................. 41 III. Novice Rationales for Sketching and Tracing, and How They Try to Avoid It .................................. 43 3.1 Introduction............................ 43 3.2 Background............................. 45 3.2.1 Tracing and other ways novices read code..... 45 3.2.2 When and why do students sketch?......... 46 3.2.3 What external representations are common in novice programming?..................... 47 3.3 Method............................... 48 3.3.1 Class observations................... 49 3.3.2 Interviews........................ 49 3.4 Why sketch (or not)?....................... 50 3.4.1 Goal and pattern recognition............. 50 3.4.2 Anticipated cognitive load.............. 51 3.4.3 Problem-solving progression: From goal search to tracing (and re-tracing)................. 52 3.5 Why not sketch like the instructor?............... 53 3.5.1 Seen as unnecessary and time-consuming...... 54 3.5.2 Visual details seem distant from code........ 54 3.5.3 Boxes are reserved for another purpose....... 55 3.6 What do novice sketches include?................ 55 3.6.1 Organizing and structuring of traces......... 55 3.6.2 Persistence of past values and calculations..... 56 3.6.3 Anchoring with visible values and structures.... 57 3.7 Discussion............................. 58 3.7.1 Search for goals and patterns is primary....... 58 3.7.2 Variables are treated differently based on context. 59 3.7.3 Past values are retained................ 60 v 3.7.4 Variables are un-boxed................. 60 3.8 Limitations and threats to validity................ 60 3.9 Conclusion............................. 61 IV. “I’m not a computer”: How Identity Informs Value and Expectancy During a Programming Activity ..................... 63 4.1 Introduction............................ 64 4.2 Background............................. 65 4.2.1 Identity, programming, and applications...... 65 4.2.2 The Eccles expectancy-value model of achievement choice.......................... 66 4.2.3 Tracing code to solve problems............ 67 4.3 Method............................... 68 4.3.1 Task........................... 68 4.3.2 Problems......................... 68 4.3.3 Participants....................... 69 4.3.4 Interview Protocol................... 69 4.3.5 Analysis......................... 70 4.4 Case Studies............................ 71 4.4.1 Charles: I’m not a computer.............. 71 4.4.2 Luke: I’m not a programmer............. 73 4.5 Discussion............................. 76 4.5.1 Previous achievement-related experiences, Inter- pretations, and Affective reactions and memories. 77 4.5.2 Goals and general self schemata........... 78 4.5.3 Activity-specific ability, self-concept, and expecta- tions for success..................... 78 4.5.4 Subjective task value: Interest-enjoyment value.. 78 4.5.5 Subjective task value: Attainment value....... 79 4.5.6 Subjective task value: Utility value.......... 79 4.5.7 Subjective task value: Relative cost.......... 79 4.6 Conclusion............................. 80 V. Defining, Building, and Evaluating Purpose-First Programming .. 82 5.1 Introduction............................ 82 5.1.1 Summary of contributions............... 84 5.2 Motivation for the approach................... 86 5.2.1 Conversational programmers and end-user programmers want to understand the purpose of complex code, but also want to avoid detailed semantics.. 86 5.2.2 Programming tools for non-developers often avoid industry- standard code, so they don’t provide dis- ciplinary authenticity................. 87 vi 5.2.3 Plans may be a more motivating way for conversational programmers to think about code..... 88 5.2.4 Other systems have provided plan- or example- based support...................... 89 5.3 Formative study: Investigating the responses of novice programmers to purpose-oriented assistance........... 90 5.3.1 Focus group results................... 90 5.3.2 Survey results...................... 92 5.3.3 Conclusions from the formative study........ 95 5.4 Defining Purpose-first programming.............. 96 5.4.1 Identifying authentic, domain-specific programming plans........................... 96 5.4.2 Expanding the definition of a programming plan to serve instructional needs.............. 97 5.4.3 Providing ”glass-box” scaffolding to support learners as they work with plans.............. 99 5.5 Designing the purpose-first programming proof-of-concept curriculum............................. 100 5.5.1 Building a set of plans................. 100 5.5.2 Creating activities................... 102 5.5.3 Selecting a platform.................. 103 5.5.4 Designing purpose-first support........... 103 5.5.5 How this prototype meets the design goals..... 105 5.6 Method............................... 108 5.6.1 Study Design...................... 108 5.6.2 Recruitment and participants............. 109 5.7 Evaluation of learners’

Load more