Paper Summary
Share...

Direct link:

Designing for Debugging: A Constructionist Approach to Debugging in Electronic Textile Projects (Poster 12)

Sun, April 16, 2:50 to 4:20pm CDT (2:50 to 4:20pm CDT), InterContinental Chicago Magnificent Mile, Floor: 3rd Floor, King Arthur Court

Abstract

Essential to computing, debugging is often difficult to learn and to teach (McCauley et al., 2008). Encountering bugs can generate fear and anxiety, leading to disengagement and the avoidance of CS (Scott & Ghinea, 2013). Typical debugging teaching practices and curricula often emphasize top-down instructionist designs that focus on small, isolated problems (e.g., Brusilovsky, 1993; Robertson et al., 2004). Contrastingly, in our approach of Debugging by Design (DbD) students create, exchange and solve buggy projects together. Exploratory work found that students expressed greater comfort and improved skills in debugging after the eight-day DbD unit (Blinded, 2021), strategically situated before the final project in the electronic textiles curricular unit where students create a series of increasingly complex projects, sewn with conductive thread and programmable microcontrollers (Blinded, 2019). Here, we apply a quasi-experimental framework to studying Dbd, asking: What did students gain from designing and solving bugs for others beyond the normal e-textile unit?
DbD builds on a longstanding tradition of constructionism, putting learners in control by designing applications for others (Harel & Papert, 1990). In DbD, learners intentionally design personally expressive, buggy (versus functional) artifacts for their peers to fix. DbD puts students in control over bugs, framing “failure” as a productive, social experience instead of a negative one (Dahn & DeLiema, 2020).
In Spring 2021, we implemented DbD virtually in nine classrooms with two teachers in high schools with high percentages of historically excluded populations (58-95% free and reduced lunch; 85-99% non-white). Using a quasi-experimental design, five classes participated in the DbD unit; four control classes spent an equivalent time doing an additional project focused on music.
Data included pre-/post- results from a validated survey instrument (N=144) with nine constructs on CS self-beliefs: CS competency beliefs, CS fascination, CS value, CS creative expression, self-efficacy in coding and debugging, programming (fixed and growth) mindsets, programming anxiety and programming self-concept. Analysis utilized correlations and MANOVA to tease apart results between groups.
Both DbD and control groups showed significant increases in several areas of the survey, mirroring results from earlier studies (Blinded, 2019). Exclusive to the DbD group, correlation analyses showed that completion rate of the e-textile unit improved students’ programming growth mindset, i.e., believing that programming is a learnable (versus innate) skill. In addition, while MANOVA results showed no differences between DbD and control groups across gender, prior CS experience, and home language groups, results highlighted the importance of the DbD unit among students in families with no college education: these DbD students showed significantly better gains than comparable control students in valuing CS for their futures, self-efficacy in coding and debugging, and programming self-concept (i.e., learning quickly, feeling strong in programming).
DbD frames debugging as productive, creative, social, and even mischievous. As a design principle, DbD can apply in many CS domains with potential to reframe CS for historically excluded students, and improve confidence in problem solving and code.

Authors