| CARVIEW |
Dr. Tamara Nelson-Fromm defends her dissertation: What Debugging Looks like in Alternative Endpoints
In May, Tamara Nelson-Fromm defended her dissertation “A Qualitative Exploration of Programming Instruction for Alternative Endpoints in Post-Secondary Computing Education.”
I’ve talked about Tamara’s work a few times in this blog.
- One of her early projects was a teaspoon language to help history teachers to build history timelines (blog post).
- At PLATEAU 2024, she presented our paper suggesting that there was transfer from the Pixel Equations teaspoon language into building Image filters in Snap! (blog post).
- She presented our paper at SIGCSE 2025 on how we designed the PCAS courses oriented towards creative expression and social justice (blog post). Tamara worked with me on that design process, particularly on how to meet justice scholars desire for their students to learn about databases, HTML, and SQL (blog post) and on helping students to understand how a computer might generate language (blog post).
Tamara has published a lot more than that during her PhD work in part because she became an expert on reflexive thematic analysis. She worked with several other students on using RTA. At SIGCSE 2026, she and Aadarsh Padiyath will present their paper on how to use RTA for computing education research. I’ve read the paper and loved it — I have been recommending it widely.
Tamara with her committee: Valerie Barr (on Zoom), (from right) Nikola Banovic, Barry Fishman, Tamara, and me
I want to tell you about her dissertation, but I don’t want to divulge too much — only the first study has been published so-far. The big idea that drives her work is alternative endpoints. She and I have talked a lot about the paper by Mike Tissenbaum and his colleagues. The big question that she’s helping to answer is “What will CS education look like as we move beyond producing more software developers?”
Study #1: New CS Teachers learning Debugging: Her first study investigated how we develop new CS teachers. From the start of her PhD, she has been interested in how students learn to debug. Her method was novel (and hard to get past reviewers). Instead of studying new CS teachers and how they learned debugging, she interviewed expert teachers of new CS teachers. She interviewed the people who run professional training, summer workshops, and many the other ways that teachers learn CS. Rather than track individuals (who might not struggle with debugging, or who might not be representative of new teachers), she talked to people who have been doing this for years. What do they do to teach debugging?
Here was the amazing answer: Avoid it. In hindsight, it makes all the sense in the world. Imagine: You’ve got a teacher new to CS in your workshop. In the first workshops (which is often all you get with teachers), you want them to succeed.. You want them to come back for more workshops. So, you do all that you can to avoid bugs. Since bugs will happen still, you provide checklists and “Here’s what to look for if it doesn’t work” guidance.
Of course, really learning to debug comes later…or does it? Tamara raises the intriguing possibility that maybe that’s enough. Maybe for what these teachers are doing (especially in primary school), maybe it’s enough to just have checklists. Again, it’s about alternative endpoints — what does a K-12 teacher need to know about debugging? The paper on her first study will appear at SIGCSE 2026 in February.
Study #2 and #3: PCAS Students: Her second and third studies involved PCAS students. In her second study, she looked at why arts, sciences, and humanities students would want to take courses involving programming. In her third study, she returned to the theme of the first study — how do PCAS students debug?
I don’t want to say too much about these studies, but I do want to tell one story from Study #3 that connects strongly to the story about teachers in Study #1. One of the ways that Tamara saw PCAS students debugging was the way that your modern mechanic fixes your car.
Mechanics today do not need to how your car actually works. Instead, they plug it into the diagnostic machine, and they get a code. The code tells the mechanic where the problem is. The mechanic then follows a procedure or (more likely) replaces a part — whatever the manufacturer guidance is for that code. They then try it again.
That’s how some of the PCAS students debugged. Each assignment for the arts and humanities classes was open-ended, and I gave them completely working examples. The students would write their programs and try them. If they didn’t work, they’d check that they didn’t make a simple mistake. If they couldn’t figure it out, they would go back to one of the worked examples and copy-paste the part that worked and did about the same thing. Then they’d test again. If they still couldn’t get it to work, they’d explore changing what they were trying to do, so that they still met the requirements — but they could get it working.
Is this problem? Do the students need to learn better debugging skills? Let’s go back to alternative endpoints again. Not everyone needs to have a strong mental model of the working program.
Tamara wasn’t prescriptive in her dissertation. She didn’t make judgements of good or bad. Rather, she described the world as she found it, and raises the reasonable possibility that what she saw is working just fine.
Tamara’s dissertation is important. The alternative endpoints paper suggested that we should think about different audiences learning to program for different purposes than software development. Tamara showed us what that is looking like.
Creating a measure of Critical Reflection and Agency in Computing
I stopped blogging while I was on sabbatical because I had to focus on finishing the second edition of Learner-Centered Design of Computing Education. And then we came back from sabbatical. I’d heard that it was tough getting back to normal work after sabbatical, and it was. I had it easier than most (e.g., I came back to summer time, and I had a light teaching schedule this Fall). But it was still a transition, so it’s taken me awhile to get back to blogging.
In the meantime, Aadarsh Padiyath published two papers (and a poster) about the the development and validation of an instrument to measure Critical Reflection and Agency in Computing. Aadarsh Padiyath is a PhD student (soon to graduate! Hire him!) advised by Barb Ericson and me. He last appeared here with a guest post a year ago with a pushback against technological determinism — computing education researchers assuming that the future of CS education can be predicted by the development of ChatGPT.
These new papers are about the second study from his dissertation. Aadarsh is interested in how we can better prepare computer sciences for recognizing and dealing with ethical issues. Typically, we do that with computing ethics classes. But do they work? Aadarsh recognizes that being able to measure progress is an important way to encourage progress.
In May, he published a paper at CHI 2025 “Development of the Critical Reflection and Agency in Computing Index.” The title captures the two aspects of computing and ethics that Aadarsh is most interested in — that student reflect on the ethical implications of their work and that they have a sense of agency, i.e., that they can do something that can address problems. This first paper was about defining the constructs (see Table 1 below). He created 45 items for his measure. He had a panel of experts review the items, and he interviewed five undergraduate students as they responded to the items. His paper was recognized with a Best Paper Honorable Mention.
Aadarsh presented a poster at SIGCSE 2025 in February, “The Development and Validation of the Critical Reflection and Agency in Computing Scale.”
The big finale was his ICER 2025 paper in August, “Validation of the Critical Reflection and Agency in Computing Index: Do Computing Ethics Courses Make a Difference?”. This paper summarized the CHI 2025 story of how the index came to be, then presented the results of a two-round validation study (474 participants in one, 464 in the other). Overall, he has strong support for the validity of his measure.
But in addition to taking the measure, Aadarsh ask the participants if they had taken a computing ethics course. He found “Participants who completed computing ethics courses showed higher scores in some dimensions of ethical reflection and agency, but they also exhibited stronger techno-solutionist beliefs, highlighting a challenge in current pedagogy.” Here’s my interpretation of his results: after taking a course in computing ethics, students were more reflective (yay!) and believed that they could make a change if they saw an ethical problem in their work (double yay!), but they tended to belief that more technology is the answer to addressing ethical problems with technology (uh-oh).
This is an impressive set of papers. It gives us a way of measuring the impact of our interventions in teaching computing students about ethics. It also highlights some real issues that we should be addressing in our computing ethics classes.
Seeking K-12 Computing Teachers With Emerging Bilingual students in their classes
Emma Dodoo is a PhD student working with me. Emma works with K-12 computing teachers who have emerging bilingual (EB) students in their classes, e.g., students for whom Spanish is their first language and who might be learning English while they are taking a computer science course. I recently wrote a blog post about her SIGCSE and PLATEAU papers on her interviews with teachers, to identify the challenges faced by EB students in computing classes and strategies for addressing those challenges.
She has been designing some new tools and curriculum, based on those interviews. She is now looking for teachers to critique the work, to be co-designers on new versions, and possibly to use some of these in their classrooms. Below is her call for participants. Could you please forward this to any teachers you know who might be interested?
We’re a team of researchers at the University of Michigan looking for a few more 7th-12th grade computing teachers to collaborate on a research project focused on supporting bilingual students in transitioning from block-based to text-based programming.
Teachers can join one or both parts of the study, be a part of a publication, and earn up to $500 (USD)! Here is a brief explanation of these studies:
Summer 2025 – Co-design a programming unit with us (tools + worksheets tailored to bilingual learners)
Fall 2025 – Try it out in your classroom and share your experience
There’s also a chance to co-author a publication. More info is in the flyer and interest form. If you have any questions, please reach out to us using: edodoo@umich.edu.
Three stories about how CS is overwhelming, and ideas for how we can do better
When we looked at how PCAS students thought about our classes (for our SIGCSE 2025 experience report), I was surprised at students’ use of the word “overwhelming” when talking about CS classes. I was pleased that they positively contrasted our courses with CS classes that they had taken previously, but I didn’t realize how much baggage the students brought with them — how negatively they perceived computer science. Some students told us how emphatically did not want a job in the Technology industry and didn’t want to take CS classes. When Tamara Nelson-Fromm interviewed the PCAS students from our first semester, she told me that every student she interviewed had tried to learn programming (via formal or informal means) and failed. That’s why they were trying the PCAS courses. Most weren’t looking for a sense of belonging in CS — they had their identities as artists or scientists or managers.
My guess is that students made this choice away from CS pretty early on. Some studies support the proposition that students make career decisions by late elementary school. We know that less than 10% of US high school students take a CS class each year (State of CS Ed Report). And while undergraduate CS classes and majors have grown, the majority of students at any University are not choosing CS. And as I described in an earlier post in this series, the kind of computing that students use outside of CS classes is different from what’s inside of CS classes.
I shouldn’t have been surprised about what students were telling Tamara. I had read about the #techLash. There is a lot of literature about how much CS overwhelms students. There’s also literature on how we can do better. Here are three of my favorite papers in this space.
“‘I like computers. I hate coding’: a portrait of two teens’ experiences” by Paulina Haduong communicates the punchline in the title. This is a rich, qualitative study of students who love to use computers, but who hated their experiences with Hour of Code, with Scratch, and with formal and informal education around programming. In the end, though, this is a positive paper. As Paulina writes, “These learners’ experiences illuminate the ways in which identity, community and competence can play a role in supporting learner motivation in CS education experiences.”
“‘I Always Feel Dumb in Those Classes’: A Narrative Analysis of Women’s Computing Confidence” by Amanda Ross and Sara Hooshangi is another paper that tells the punchline in the title. Amanda is completing an Engineering Education PhD at Virginia Tech, and has accepted a job at Rose-Hulman (congratulations both to her and Rose-Hulman!). For this paper, she interviewed women who succeeded in introductory CS and had high self-efficacy, but still dropped out of computer science.
Results show that while participants were highly successful in their course (reporting a high mark in the class) and had relatively high self-efficacy when discussing specific programming problems, they lacked computing self-concept in whether or not they were good at programming in general.
These first two papers show women who are interested in programming and who are good at it, but struggle to succeed in CS education. Why? Maybe it’s because of how we frame the field of computer science.
Being a software developer is a hard job — you translate requirements to code, and you aim for the code to be robust and secure. Most people who program (scientists, artists, end-user programmers, critical computing scholars, etc.) are programming for themselves, to achieve a goal of their own or to express themselves. It’s only the minority of programmers, the professional software developers, who code primarily for others. So, I understand why classes to prepare future software developers are about the hard task of precisely converting specifications to well-tested program code. But that’s maybe 10% of people who program.
The field of computer science has developed a narrow frame. We could have a broader one, one that includes the way that other disciplines use programming. I argued in an earlier post that we can broaden participation in computing by making computing education broader than just what CS and the Tech industry wants.
I have been telling people about this talk by Felienne Hermans from SPLASH 2024, “A Case for Feminism in Programming Language Design.” I highly recommend her paper with co-author Ari Schlesinger (which you can find here), but if you are interested in how computing became so male and so uncomfortable for female students, you must watch this talk. It’s a compelling and thought-provoking story, which I found both emotional and insightful. Watch through the Q&A if you want to get some additional evidence that Felienne is right about how she describes the field and how computer scientists push against a broader framing.
I appreciated Felienne’s point that computer science has confused “hard” with “interesting” or “valuable.” We overly value things that are hard to do, which leads us to undervalue things that are interesting, valuable, or useful but are not necessarily hard to do (e.g., studying how people build in Excel is interesting and valuable, even if it’s not as “hard” as studying programmers building million LOC systems). I have heard this sentiment voiced lots of times. “The study was really not that much. I don’t see why it’s interesting.” “The system wasn’t hard to do. Anyone could have built it. It’s not really a contribution.” “Anyone could have thought of that.” An academic contribution should be judged by what we learn, not by how hard it was to do or invent. That focus on being hard is part of what drives students away from computer science.
Felienne and Ari’s paper helps to explain tension between Computer Science departments and Computing Education Researchers. CER work doesn’t look like CS “hard” work. My students don’t typically build a big piece of code that gets used by thousands. Some of my students tested educational psychology theories in a computer science context (see blog post about Brianna Morrison’s work as an example). Some of these experiments are replication studies. There’s an obvious hypothesis — that what was seen by educational psychologists in other fields would likely be true in computer science, too. Whether the replication worked or not, the findings are novel contributions to CER because they tell us something that we didn’t know before.
Making computer science classes more welcoming and inviting isn’t about changing the nature of computer science. Paulina, Amanda, and Felienne are talking about and with people who love working with computing. The goal is not to reduce rigor. The goal is to remove unnecessary constraints. We can allow students to express themselves in computer science classes. We don’t have to make students feel dumb in computer science classes. We need to be open to broader definitions of what counts and is important in CS. We need a larger frame for the field of computer science and the goals of computing education.
I started this blog post series in February, describing how we designed the PCAS courses for arts and humanities students. The next post described how computing education was different than CS education. I offered two posts on computing education in the arts and and in the sciences. My previous post was a recommendation that CSTA (and primary and secondary school overall) focus more on computing education for everyone and less on CS education. I’m ending the series here with a post on how to make computing education work for all students, whether aimed at technology for their career or not. I’m making an argument for computing education for all and even more specifically programming for all. The way we get there is by looking at how the whole word uses computing and programming, not just what the computer scientists want.
School teachers don’t need to recruit students into CS: An alternative model for K-12 computing education
The Computer Science Teachers Association (CSTA) is in the process of updating their influential standards. It’s a long process, and it started last summer with a visioning document called “Reimagining CS Pathways.” Part of their new reimagining includes dispositions which are meant to cross all content and skill areas.
I am arguing here that “Sense of Belonging in CS” should not be in that set. The role of computing education in K-12 should be to introduce students to computing for whatever they are going to do in life. As I’ve been pointing out in the last few blog posts, the uses of programming in science, arts, and humanities don’t look like CS classes. Computing education is different than CS education, as I described in the blog post that started this series. K-12 computing education should not be about convincing students that they belong in CS, but should be about giving them the confidence that they can use computing in whatever career they choose.
I made a critique of this dispoition on social media, and the responses suggested that I look more carefully at the document. I was told that there is strong research supporting the need for “sense of belonging in CS.”
Here’s the text of the document introducing this disposition:
A sense of belonging, or the “personal involvement (in a social system) to the extent that the student feels that they are an indispensable and integral part of the system” (Anant, 1967, p. 391), is one of the more widely researched dispositions in CS education. Its importance is linked to its relationship to a student’s sense of their own ability in (Veilleux et al., 2013) and interest in persisting in their studies (Hansen et al., 2023). Sense of belonging is an important facet of ensuring equity in CS, since this sense often differs by student demographic group (Krause-Levy et al., 2021).
That’s a really strong definition of “sense of belonging.” I don’t think that even the most welcoming undergraduate CS classes and programs aim to make students feel that they are “an indispensable and integral part” of computer science. I looked up all three of these references (and linked each of them above). Here is the first sentence of each of those papers:
- Veilleux et al., 2013: “Retaining students in computer science majors has been a persistent topic among computer science educators for almost two decades.”
- Hansen et al., 2023: “The purpose of this longitudinal investigation was to examine the effectiveness of a comprehensive, integrated curricular and co-curricular program designed to build community, provide academic and social support, and promote engagement in academically purposeful activities resulting in more equitable environments for historically underrepresented, low-income science, technology, engineering, and mathematics (STEM) information technology (IT) students.”
- Krause-Levy et al., 2021: “Students’ sense of belonging has been found to be connected to student retention in higher education.”
None of these are about K-12 education. All of them are about CS, IT or STEM majors in higher education. The goal of “sense of belonging in CS” is undergraduate retention in the higher-education major in these papers, not K-12 students persistence at learning computing that is useful for them. The goal of K-12 education is to prepare students to be CS, IT, or STEM majors — or arts, humanities, business, or anything else majors, or to be successful citizens in a technological society, even if they don’t go to college. I don’t see any literature cited in the document that tells us how important a “sense of belonging in CS” is to K-12 students and their success in learning about computing.
An Alternative: Everyday Computing
We need a model for K-12 computing education that recognizes the value of alternative endpoints, as Tissenbaum, Weintrop, Holbert, and Clegg have described it (BJET link, UIUC repository link). K-12 CS education should not be a jobs program for technology companies.
Here’s an alternative model. The University of Chicago has a mathematics curriculum called “Everyday Mathematics.” Here’s how they describe it:
Everyday Mathematics is a research-based and field-tested curriculum that focuses on developing children’s understandings and skills in ways that produce life-long mathematical power.
The Everyday Mathematics curriculum emphasizes:
Use of concrete, real-life examples that are meaningful and memorable as an introduction to key mathematical concepts.
…
Each grade of the Everyday Mathematics curriculum is carefully designed to build and expand a student’s mathematical proficiency and understanding. Our goal: to build powerful mathematical thinkers.
I didn’t study Everyday Mathematics when I was a kid, but the description resonates with how I remember my own math classes. I saw math problems relating to cooking, engineering, craft, orienteering, map making, and lots of other domains. The mathematics education was contextualized to support students in seeing the connections and relevance of mathematics to their lives, to what they thought was important. My mathematics teachers were preparing us to be mathematical thinkers, not necessarily mathematicians. I enjoy mathematics, and use it often, but I don’t think of myself belonging in math.
We need Everyday Computing. Our goal in K-12 education should be to build powerful computational thinkers. We need to relate computing education to the things in students’ everyday lives, and that they’re likely to see in their lives. At the second and post-secondary level, we should help students to think about the computing that they’re already using, like R and Python, with vector operations and a focus on data over algorithms. We need school teachers to show students that computing is for them, not that they belong in computing.
Recently, the CS for California organization rewrote their mission and vision statements. I like them as a model for what CS education should be nationally.
Our New Mission: Advance equitable computer science education for all California students by fostering inclusive engagement and community partnerships, strengthening support for educators, and informing policy through data.
Our Vision for the Future: California students are equipped with foundational computing competencies to become innovative thinkers and creators of a just and inclusive future.
It’s not about creating computer scientists or technology workers, though those are possible endpoints. It’s about supporting students whatever they want to become and using computing to get there.
How scientists learn computing and use LLMs to program: Computing education for scientists and for democracy
Gabi Marcu is a professor in the University of Michigan School of Information who studies technologies to promote health (see her website). She’s also an improv performer, and a friend. She asked me to participate in her project to combine research and improv called “Extra Credit.” She asks researchers to explain their research in 10 minutes, then a group of improv artists riff on the research for another 10 minutes.
The first speaker in the session I participated in was Joyojeet Pal, who studies social media and politics. He was hilarious — I heard one of the improv performers quip, “Wait — it’s our job to be funny!”
I talked about what everyone needs to know about computing to support democracy, with a focus on our recent course on AI. Barb recorded it and allowed me to share it.
I learned the most from hearing and meeting Elle O’Brien (see her website). Elle is a computational neuroscientist who decided to go meta. She now studies how scientists learn and use computational methods.
She had a paper in Harvard Data Science Review last year on how scientists learn computational methods, “In the Academy, Data Science Is Lonely: Barriers to Adopting Data Science Methods for Scientific Research.” In her study, it didn’t go well:
These scientists quickly identified that they lacked the expertise to confidently implement and interpret new methods. For most, independent study was unsuccessful, owing to limited time, missing foundational skills, and difficulty navigating the marketplace of educational data science resources.
I was surprised how much the scientists in her study needed more curation. There’s no lack of ways of learning data science — videos, tutorial, MOOCs, books, bootcamps, and on and on. But Elle was talking to working scientists. They were busy professionals. They struggled to find the right learning materials for their level of knowledge that matched what their field used.
Elle and I have both noticed how many different computational cultures there are across the sciences and liberal arts. These scientists use R, and these others use Python — even in the same department. They talk together about their science, but not really about code. Computational artists I’ve met at Michigan only use Processing or Unity. I’ve learned that Economists at Michigan mostly use Stata, a tool that I’d never heard of before my informants (two Economics faculty and PhD student) told me about it. While programming is common across the sciences, actually taking CS classes is rare among scientists that we’ve worked with. Most of the programming science faculty we met are self-taught, or learned through apprenticeship from the labs and groups they came up through.
Elle observed that computational scientists she works with are increasingly multi-lingual. They might use Python for some of their tasks (data processing, data cleaning, modeling, and/or simulation), then use R for statistics and visualizations. They are making choices for programming languages based on the libraries and communities that use those tools, not on the characteristics of the languages themselves. I’ve worked with some scientists who also work in multiple language ecosystems, but within the constraint that they’re trying to optimize their time. They’re not trying to transfer their knowledge of programming from Python to R — they’re just trying to get their work done. “Recipes” of how to do things in R are just fine for them.
Elle tries to convince some of her scientists to consider using version control systems, but they don’t see much benefit. Few scientists that either of us work with are inventing new abstractions. They write code (often, no more than a screenful) to get a job done, then throw the code away. They care about the data and the results, not the code. If you don’t invent new abstractions and you don’t reuse code, what does Github buy you?
Elle has a new paper appearing in CHI 2025 that is fascinating and relevant: “How Scientists Use Large Language Models to Program.“ She finds that “scientists often use code generating models as an information retrieval tool for navigating unfamiliar programming languages and libraries.” Again, they are busy professionals who are trying to get their job done, not trying to learn a programming language.
I was impressed with how much effort the scientists that she studied put into checking what the LLMs produced. One scientist ran code in a familiar system to compare to the results generated by the LLM-generated code. They all wisely distrusted the LLM code, more than I usually see computer scientists (and especially computer science students) who may not check LLM-generated code.
And yet, the LLMs still inserted bugs that the scientists missed. LLMs are absolutely nefarious in how and where they generate bugs. Elle raises the possibility that LLMs are having a negative influence on the scientific enterprise.
Elle is engaging in computing education research, though I don’t think that she thinks of herself that way. She’s not likely going to submit anything to ICER or the SIGCSE Symposium anytime soon, but computing education researchers need to know about work like hers. She’s studying scientists from the lens of being a scientist who uses computing, not a computer scientist. She knows more about what scientists need from programming and how they learn programming than most computer scientists or computing education researchers I know.
My Favorite ICER 2024 Paper: How Media Artists Teach Computing
I’m hesitant to state a preference for my favorite paper at the International Computing Education Research (ICER) Conference in 2024. There were so many cool papers (including some by my students!). But it’s an easy choice if I use the heuristic, “Which paper have I still been thinking and talking about the most after the conference?”
My favorite paper of ICER 2024 was Alice Chung and Philip Guo’s paper “Perpetual Teaching Across Temporary Places: Conditions, Motivations, and Practices of Media Artists Teaching Computing Workshops.” It’s a study of real media artists who teach computing in workshops. The first sentence of the paper is “Why and how do new media artists teach computing?” I love this question, and the answers are fascinating.
One of their observations is that media artists teach as part of their practice. They’re always learning new tools and practices, and also always sharing them. Let’s contrast this with software engineering. How many professional software developers also teach software development? How many consider it integral to their practice? Or swap the question — how many CS1 instructors are also professional software engineers?
Our study finds that artists strategically understand and respond to these conditions, developing what we call perpetual teaching – reframing the internalized duty or responsibility of perpetual training into pedagogical frameworks
So why? Why would media artists spend their time teaching? It’s about trying to be critical about what they’re doing.
We found that artist-educators are motivated by creating spaces to unlearn ineffective conventions and incubate new cultures rather than by technical knowledge transfer alone. Furthermore, they intended to design their workshop materials (e.g., prompts, activities, reading lists) to prepare participants to create critical interpretations of computing outside of mainstream tech career pipelines.
This is such an interesting goal and a contrast with computer science education. Artist-educators want to make new things and explicitly contrast with traditional technology paths. They want their students to be media artists who are critical of what’s happening in the rest of computing. Explicitly, media artist-educators are focused on alternative endpoints in computing education.
The paper goes into much more depth with examples and quotes from the artist-educators about their goals and motivations. I highly recommend reading the whole paper. It’s well-written and grounded in education literature.
I have had more conversations about this paper than any previous ICER paper that I am not co-author of. In most of the conversations, a computing education researcher was critiquing the paper, and I was defending it. The biggest critique I heard is that the paper does not speak to CS educators’ issues and offers them no solutions to their problems.
I mostly agree, but that’s what’s why I’m so excited about this paper.
The International Computing Education Research (ICER) conference should be about more than computer science education. Of course, it’s important to study CS1 classes, CS majors, and how to produce great software developers. We need good CS education, and we need research on what’s going on in CS education and how to make it more successful — which includes studies of teachers. But there will be far more people programming than will ever take a CS1. Studying how people learn computing beyond CS and how to make their learning successful is important for our modern society. That’s computing education, and ICER needs to have more papers like this one that explores the much larger world beyond traditional CS education.
But in the best possible world, this paper does speak to CS educators, too. Alice and Philip write:
New media artists view teaching as a means to promote greater diversity in computing cultures, emphasizing education’s role in broadening participation and challenging traditional narratives.
Wouldn’t we wish that to be true of all CS educators, too?
CS doesn’t have a monopoly on computing education: Programming is for everyone
I participated at the first SIGCSE Virtual Conference last December. I was on a panel “Assessments for Non-CS Major Computing Classes” (see the ACM DL paper here). The panelists were excellent. I was excited to meet Permit Chilana who came up with the idea of conversational programmer in her 2015 VL/HCC paper. Her talk was particularly relevant to me because she emphasized how she is studying business students, not computer science students — her research is about how non-CS students interact with computing and programming. Jinyoung (Jina) Hur was our organizer, and she ran the panel, which it left to her advisor, Katie Cunningham to present their fascinating work contrasting conversational programmers and end-user programmers in the CS classroom, which appeared at ICER 2024 (see paper here). Katie also shared some of her studies of conversational programmers starting from her dissertation work. Dan Garcia presented his work (with Armando Fox) on mastery learning which gives even non-CS majors the chance to get top grades in introductory CS classes (see nice piece that Berkeley Engineering wrote about their effort).
My talk was about what we’re accessing non-CS majors on. My claim is this: Computing education for non-CS majors is different than what we teach CS majors. It is important to figure out why non-CS majors are taking courses designed for CS majors (maybe they want to be conversational programmers or end-user programmers?) and to make sure that they can succeed (including getting good grades) when they are in those classes. However, it’s even more important to figure out the learning needs of the non-CS majors around computing and how to meet those — and then, how to assess the learning in meeting those needs. Education for CS majors is different from what non-CS majors need.
Here are a few examples of what I mean:
- When I asked Social Justice scholars what they wanted their students to know about computing, the top learning objective was for their students to understand that websites can be built from databases (see blog post about that story and our recent SIGCSE 2025 paper). Most CS majors probably don’t learn this.
- My colleague Gus Evrard led the effort to build our Python Programming for Sciences classes. He got four different departments (who were already teaching Python) to collaborate to define this new course. The course is about SciPy, cleaning data, Numpy, and building data visualizations with libraries like MatPlotLib. Most data science programs cover these topics, but most computer science programs don’t.
- I’m pretty sure that the most popular programming language (in terms of number of people using it) on most campuses is R. All of Statistics is taught in R. It’s very common in Psychology, Anthropology, and Sociology. Natural Sciences (chemistry, biology, physics) is increasingly using R for statistics and visualizations, even if they use Python for data management, modeling and simulation. I haven’t found a computer science program yet that teaches R or computer science through R, e.g., explaining to students the computer science that is most relevant to them.
- End-user programmers most often use systems where they do not write loops. Instead, they use vector-based operations — doing something to a whole dataset at once. (Kind of like the higher-order functions that Kathi Fisler used to beat the Rainfall Problem.) Many scientists use R and Numpy on Python. Many Engineers use MATLAB. Yet, we teach FOR and WHILE loops in every CS1, and rarely (ever?) teach vector operations first. The K-12 US state CS standards I’ve read explicitly include loops — teachers have to teach loops to meet the standard. End-user programmers likely outnumber traditional software developers (see some estimates). So why are we first teaching the stuff that fewer people use (hard-coded loops), requiring students to learn the harder forms?
Here are the points that I want to make over the next few blog posts. Many, many people are programming today. A minority of them are professional software developers. Learning to program is a form of computing education, but computer science is not typically teaching the things that non-CS majors need to program, so computing education is moving away from Computer Science (field, departments, teachers). Computer science no longer has a monopoly on computing education.
Here’s how I’m using these terms. Computer science education is teaching students about computer science. For the most part, CS education has become focused on developing professional software developers and other workers for the technology industry. Computer science (as a field or a department) has a lot of definitions, some of which I present when I give talks (below, and in this blog post). (Notice that the K-12 definition still includes “impact on society” but ACM/IEEE dropped that out in the 2021 Computing Curriculum volume.)
My favorite is the original one from Perlis, Newell, & Simon (1967): “The study of computers and the phenomena surrounding them.” But most computer scientists balk at how broad that one is. So, let’s call that “computing” and preparing students to work with computing (explicitly including programming) in whatever field they do computing education.
Computer science departments should offer computer science educationWe obviously need lots of people who know computer science, including many professional software developers. But most people who program will not be computer science majors (e.g., see this 2017 Oracle study). The needs for computing education must also be met.
(Side note: It is an interesting question: If students’ computing education needs are not being met, whose job is it to figure out a solution? Here at Michigan, individual departments were making classes to teach students the programming needed in their discipline, but now we’re combining them in PCAS. I’d wish that computer scientists would work to meet those needs, but computer science today is mostly about developing future technology workers. I am grateful that U-M’s College of Literature, Science, and the Arts started PCAS.)
The breakup of the CS monopoly is a particularly good thing for computing education researchers. There is SO much to do! So much of our research in the SIGCSE community is about CS1 for future CS majors. But computing education research doesn’t have to be about CS majors, and doesn’t have to be about CS1. There is so much more to study and explore when we think about how artists, scientists, business people, designers, architects, and humanities scholars, and everyone else learns about and uses programming.
Designing Courses for Liberal Arts and Sciences Students Contextualized Around Creative Expression and Social Justice: SIGCSE 2025 Experience Report
I am sorry to miss the SIGCSE 2025 Technical Symposium this week. I so want to hear Mitchel Resnick’s keynote for his Outstanding Contribution award, and to cheer on Manuel Pérez-Quiñones for his Distinguished Service award. There’s going to be a great session on “Ethics, Power, and Persistence” with papers from ACM TOCE, including a paper by Aadarsh Padiyath (see his recent blog post here) whom I co-advise with Barbara Ericson, and a paper by Noelle Brown, on whose dissertation committee I served.
Barbara and I are in New Zealand on sabbatical. We are Visiting Erskine Fellows at the University of Canterbury in Christchurch.
Tamara Nelson-Fromm and I have an Experience Report at SIGCSE 2025, which she will be presenting, “Designing Courses for Liberal Arts and Sciences Students Contextualized Around Creative Expression and Social Justice.” Preprint available here.
Readers of this blog have read some of the story in this paper. We point out that the early computer science scholar wanted everyone to learn programming, from reasons other than getting a job (a story I tell in this blog post). Most of what we have done in computer science education research has been focused on preparing students for jobs as software developers. We are still learning to develop design processes for alternative endpoints (see this blog post). In a paper that Gus Evrard and I presented at the Koli Calling conference in 2023 (see paper here), we tell the story of learning what liberal arts and sciences faculty want from computing education and then developing the Program in Computing for the Arts and Sciences. We describe the participatory design process for the first two courses in PCAS: COMPFOR 111: Computing’s Impact on Justice: From Text to the Web and COMPFOR 121: Computing for Creative Expression. I told some of that story, and showed the results of the participatory design process in this blog post.
This new paper adds an evaluation of the design. Tamara in her dissertation is looking at the motivations and process of students in these classes, so she had terrific interviews with the students that addressed the design of these classes. We had put questions into the students’ course evaluations to ask about our design. We used all of these to investigate what worked and what didn’t in the class.
I’ll summarize the results here:
- Students felt that the classes were useful, and not “overwhelming.” I was surprised that students used that word when talking about the class. We aimed to create undergraduate courses in programming that students would perceive as easy, but students still commented on the workload and how they expected it to be “overwhelming.” It’s hard to underestimate just how scary students find coding classes.
- Students feel that they are now able to talk about programming and learn more programming. Helping students to become conversational programmers was an explicit goal for the class. The Runestone ebooks that show students code in Python, SQL, HTML, and Processing help.
- Snap! works well, but students need some convincing. Students are amazed at the “cool things” they can make in Snap!. But some students said that it wasn’t “real” programming. One student said that it was “demeaning” at first to be asked to use blocks-based programming, but then they realized that they were actually learning a lot about “general computer science.”
Beyond the paper
The Computer Science Division here at University of Michigan wrote a very nice article about PCAS here. Perhaps the most convincing evidence that the PCAS courses are working are the enrollment numbers. We just surpassed 500 students enrolled in our courses this summer. Students want these classes, even when they’re not required of anyone.
We’re able to scale because there are a bunch of us teaching PCAS courses. My Physist colleague on the task force and in directing PCAS, Gus Evrard, created and is teaching our 101 course, The Transistor Disruption: How a tiny tool transforms science and society. We hired a lecture, Brian Miller (PhD in Music), who has been teaching the Creative Expression and Social Justice courses — and doing a great job developing them. There’s now an exciting data visualization unit in the Expression class, and due to his efforts, the Justice class has been approved for the Race and Equity requirement in LSA — the first computing course at Michigan to receive that approval. We just hired a lecturer this semester, Donovan Colquitt (PhD in Engineering Education), to teach the Expression class and the MediaComp Python class. A bunch of PCAS courses are taught by faculty across LSA: Sara Veatch from Biophysics is teaching the Python for scientists course, Andy Marshall from Anthropology developed an R for scientists course, and Andrew McInnerney of Linguistics now teaches the “Alien Anatomy” course on Generative AI. We also have terrific staff — Tyrone Stewart as our Academic Program Manager, and Kelly Campbell who is our chief administrator and who helps us figure out all the bureaucracy of creating a new program.
Today, I’m the only person teaching COMPFOR courses who has a computer science graduate degree. That may be the secret sauce to making PCAS scale — it’s not about computer science (field, major, or department). It’s about liberal arts and sciences faculty teaching the computing that their students need to succeed.
How K-12 CS teachers support students for whom English is not their first language
Emma Dodoo is an Engineering Education Research PhD student working with me. She was born in the United States but grew up in Ghana. Her world growing up was multi-lingual and multi-cultural. When Emma took her first computer science classes, she was surprised to find that the curriculum was not only dominated by English but that it was virtually impossible to learn programming without also learning English terminology. She won an NSF GRFP to explore how to support students for whom English isn’t their first language (emerging bilinguals (EB)) taking CS courses.
Over the next two weeks, she’s presenting two papers from her first study. She interviewed US-based K-12 computer science teachers who have EB students in their classes, to ask them about the challenges that they saw EB students facing, the teachers’ strategies for dealing with those challenges, and their programming tool choices based on the EB students’ needs. She showed them a variety of programs (in blocks, in teaspoon languages, in different text programming languages) as design probes, for them to say what they liked and disliked.
At the SIGCSE 2025 Technical Symposium (program here), she is presenting the challenges and strategies that the teachers identified. (Pre-print of her paper available here.) Here’s my over-simplified take on what she learned. (Be sure to read the whole paper to get the important nuances that the student reports and the advisor glosses over.) The cognitive load for EB students in CS classes is enormous — learning CS and learning English at the same time. They’re going to get lost. There’s no way to avoid it. So teachers build in touchpoints for the EB students to synch back up with the class. The teachers emphasize color (e.g., for keywords in the IDE) and pictures (e.g., in diagrams) to provide non-linguistic ways for EB students to figure out what’s going on.
At the PLATEAU 2025 workshop, she is presenting a paper on how K-12 CS teachers make programming tool choices with the needs of EB students in mind. (Pre-print available here.) The trade-offs here are much more complicated. The teachers told her that block-based programming languages are a huge win — colors, non-linguistic information in the form of block shapes, and the ability to localize the terms in the blocks. BUT, the CS teachers are concerned for their EB students as immigrants to the United States. The teachers want students to be able to have job skills as soon as possible, because it’s important for their and their family’s success. So many of the high school teachers emphasize Python and software engineering skills.
This is such a hard trade-off. Nobody gets a job programming in a block-based programming language. Text programming languages can scare students off. Teaspoon languages or blocks-based programming languages could create a welcoming on-ramp to programming that could lead more CS classes later. Balancing these trade-offs in an instructional design is what Emma is working on next in her dissertation.
Media Computation in Python running in Google Colab Notebooks
Here’s why I decided to work on yet-another implementation of a Python API that we first developed in 2001, how to get the implementation, and how it’s different.
Why we needed Python MediaComp in the browser
In 2002, we created a course at Georgia Tech called “Introduction to Media Computation.” Georgia Tech required all liberal arts majors to take a course in computer science, but the withdrawal-or-failure rate was high (about 50% for some majors). The core idea of Media Computation (MediaComp) is to program on the digital media in their lives, at different levels of abstraction: pixels in pictures, samples in sounds, frames in video. Students succeeded at the MediaComp course at a much higher rate (about 85%).
We developed MediaComp, studied it, and disseminated it. Barbara Ericson and I wrote textbooks using MediaComp (in Python and Java), and Barb developed “Picture Lab” for AP CS A. I presented a paper at ICER 2012 that summarized the research on MediaComp in the first decade of its use, “Exploring Hypotheses about Media Computation” The effect on retention had been documented at multiple institutions, and the qualitative data suggested that it was because the focus on media made the course seem more “relevant” and thus, more motivating which increased retention. We saw it as a form of contextualized-computing education.
I complained the last time I blogged on MediaComp (in 2021) that it was hard to teach MediaComp in Python today. We had created the JES IDE (Jython Environment for Students), but that required Java (which has been increasingly hard to install) and Jython (which was no longer being actively developed). I said in 2021 that best bet I knew for teaching MediaComp in Python was the JES4Py library.
I started teaching COMPFOR 121: Computing for Creative Expression at the University of Michigan in Fall 2022 based on participatory design with groups of liberal arts faculty. It’s a course that uses teaspoon languages, mostly Snap!, and some work in Python in a Runestone ebook (see ITiCSE 2023 papers on this progression). It covers everything we did in MediaComp at Georgia Tech, and a bunch more. (Snap! is so cool.) The course works (more on that in a blog post in a couple of weeks), but not all liberal arts faculty were happy about us using non-mainstream languages. I mostly heard calls for Unity or Python. I decided to create a MediaComp Python course for PCAS, but instead of being an introduction to computer science, the goal was to provide an introduction to digital media to arts and humanities students, with Python as the manipulation language.
I taught COMPFOR 221: Digital Media in Python in Winter 2024 based on the JES4Py library and the Thonny IDE. The library is great, stitching together other Python multimedia libraries. The contributors have done a marvelous job of replicating the IDE that we had in JES. But it requires students to install Python, and that became a showstopper. I learned that many liberal arts students at the University of Michigan don’t update their OS, and keep very little disk space free. We spent a huge amount of time figuring which version of which library could actually run on their OS, and then which other libraries had to be rolled back to previous versions because of interactions. (Many thanks to Ben Shapiro at U. Washington Seattle and Apple who helped me debug some of these and figure out workarounds.) About a third of the class couldn’t do everything we asked for in the Final Project because we just couldn’t get all the libraries to work on their computers.
We needed a browser-based solution. So I devoted a chunk of my time in Summer 2024 to getting a version of JES4Py to work in Google Colab notebooks. I picked Google Colab because it offered a way for me to make audio players in the notebook (to heard digital sounds) and it easily connected to students’ Google Drives, so that they could use their own photos by simply copying them to the right directory in their Drive. We used it in Fall 2024, and it worked well! Few technical details, and students could do a lot of MediaComp Python. A new lecturer in PCAS is teaching with it now in Winter 2025.
Side note: This was my first time developing code in the post-ChatGPT world. What a wonderful tool! It had read all the documentation, and gave me examples of each thing I needed. Every generated example was wrong somewhere, but it was exactly the right example to tell me how to do what I wanted. It was great for a more experienced (but infrequent) developer like me who could interpret the results, but oof, I’d worry about students being led astray.
Using JES4Py Colab
Here’s a zip file with code and some sample media: https://computinged.wordpress.com/wp-content/uploads/2025/01/mediacomp.zip.
The assumption in the class is that you would have a folder in your Google Drive (“COMPFOR221” for us, mediacomp for the demo below) in which there were two folders: code and mediasources. Whenever students wanted to add another picture or sound (or image sequence for movies), they just copied it to mediasources.
The first cell in all our notebooks looks like this:
from google.colab import drive
drive.mount('/content/drive')
import sys
sys.path.append('/content/drive/My Drive/mediacomp/jes4py_colab')
from jes4py import *
setMediaPath("/content/drive/My Drive/mediacomp/mediasources/")
This code mounts the student’s Google Drive, modifies the sys.path to access the code directory, then imports the jes4py library. Then it sets up media folder to point to the mediasources folder. When you execute it, Google asks you (several times) if you’re really, really sure that you want to use a notebook to manipulate your Google Drive.
Here’s a demo notebook to see how this works. Remember that you’ll need to download the zip file and expand it in your Google Drive before the notebook will work for you, but you can open the notebook without the zip file — you just won’t be able to execute any of the code.
The “Hello World” sequences from JES work fine.
We can manipulate pixels.
And we can manipulate samples (shifting sounds up and down in frequency).
What’s different in JES4Py Colab
The biggest difference with JES4Py (or JES) was that there are no file dialog boxes. So functions like pickAFile() and pickAFolder() don’t work.
The second big difference is that I couldn’t get sound to play as a background process. Instead, audio objects get returned to the Colab notebook, and that generates a player. Functions like blockingPlay() don’t work, since there is no background process to block. Audio took the biggest effort. I had to re-work the way that WAV files were read in so that they could match to the audio object that Colab notebooks understand.
Pictures work really well. I didn’t have to change much from JES4py. I mostly had to fix the show() function. It doesn’t open a new window — it shows the picture in the notebook. Window-oriented JES functions like repaint() don’t work.
Movies work, but they are kind of clunky. An image sequence (directory of picture files numbered in consecutive) can be played as a Movie object, but basically, the notebook just fetches each image and displays it, trying to achieve the given frame rate. Depending on the size of the picture objects and the speed of the network, it can work. To make an image sequence, you create a folder in your mediasources directory to store the image sequence, then generate the images there. Then you can play it back in the notebook. For my students, this was enough to do debugging, and then they used the frames in some other tool (like Adobe Premiere) to generate movie files from the image sequence.
I took a PDF of the JES help files for pictures and sounds and marked them up for changes in JES4Py Colab. They’re available here: Pictures and Sounds.
Disclaimer: The best way to release this would be to set up a GitHub repository, and let people grab it and share revisions. I’m not interested in championing another open source project. I plan to keep this running for our class at the University of Michigan, and I invite anyone else to use the code without warranty or guarantee. I welcome someone else to set up a project and put this in a repository, if they’re interested in being the library owner.
Dr. Bahare Naimipour defended her dissertation
I’m on sabbatical this semester, so I finally have time to catch up on some long overdue blog posts.
Bahare at her defense with her committee: From left, Barbara Ericson, Shanna Daly, James Holly Jr., Bahare, me, and Tammy Shreiner.
Dr. Bahare Naimipour successfully defended her Engineering Education Research dissertation this last August 2024, Supporting Social Studies Data Literacy Education: Design of Technology Tools and Insights from Expert Teachers and Teacher Change Journeys.
I’ve posted about Bahare’s work over the years. She had a poster in 2019 about our first participatory design sessions aimed at understanding what social studies teachers wanted in data visualization tools (see post here). She has been working on the NSF grant that Tammy Shreiner and I received in 2020 to study how social studies teachers adopted data literacy (announcement of that grant here). Bahare had a paper at FIE 2020 (presented virtually, as that was during the pandemic) on how social studies teachers interacted with programming-based data visualization tools (post here). She compared programming and non-programming tools at SITE 2021 (post here). The tool that we created, DV4L, was the first of what we later called teaspoon languages — here is the post where we talked about a couple of teaspoon languages for social studies education.
Bahare’s dissertation is made of three related studies. The abstract from her dissertation is below. Here’s my quickie summary of the three studies, framed for a computing education audience.
First, Bahare describes the long process of developing DV4L — across multiple participatory design sessions, both in-person in Tammy’s pre-service classes before the pandemic, and on-line with in-service teachers during the pandemic. She articulates the features of DV4L which are specific to social studies teachers and describes how they were developed in response to teacher needs. This chapter has been accepted as a paper in J-PEER.
Second, Bahare followed three teachers for two years as they (slowly) developed data literacy plans for their classrooms that used technology. This is such a rich story. Bahare frames it in terms of Guskey’s Model of Teacher Change. Guskey said that teachers don’t change because of professional development. They have to have some interest in change, or they wouldn’t be taking the professional learning opportunities seriously. They actually change when they try something in the classroom and the students’ response convinces the teacher that a new approach might work. Bahare watched that happen, but found that it was even more iterative than Guskey describes. Her teachers took multiple professional development sessions before they might even try something. She saw teachers try something…and get it wrong, and with some encouragement from Bahare, try again. This study really gives you a sense for what it’s going to take to achieve CS for All across the curriculum.
Finally, Bahare interviewed exemplary social studies teachers (selected by some pretty tough criteria) and asked them how they implemented data literacy in their classrooms. Bahare saw patterns across what the teachers were doing, and those data literacy design patterns are going to feed into future professional learning opportunities. The amazing thing for this audience is almost none of them used any computational tools. They liked our tools when Bahare demonstrated them, and maybe some might adopt — but I doubt it. They are excellent teachers recognized for their skill, and they got there without computation. Why would they change now? Maybe if we showed them how much more they could do with computational tools. Maybe if we showed them how easy it could be. Those are possibilities for future studies.
All told, Bahare has written a remarkable dissertation. It’s about data literacy in social studies education, but more, it’s about the challenges that face us as we bring the power of computing beyond the STEM classroom.
Abstract
This dissertation aims to contribute to the K-12 engineering education literature in a social studies context. Data literacy (DL) is the ability to understand and interpret what data means by drawing conclusions from patterns, trends, and correlations in data visualizations (DVs). DL is part of K-12 U.S. social studies standards making it relevant for engineering education researchers since it intersects both engineering and social studies. All K-12 students take social studies classes, yet most people are not data literate. Research suggests that social studies teachers have insufficient resources for teaching DL, so not all social studies teachers teach it. The goal of this dissertation is to shed light on the topic of K-12 DL in social studies by exploring three research questions:
- When designing engineering tools for non-STEM social studies teachers, what design considerations should be met?
- How do K-12 social studies teachers choose to explore data literacy in their pedagogy after participating in a data literacy professional learning opportunity (PLO)?
- How do expert social studies teachers use and explore DVs in their pedagogy, describe their data literacy pedagogical strategies, and explore/use technology tools to support their data literacy pedagogy?
To answer my first research question (Study 1), a participatory design (PD) approach was used to learn what social studies teachers (both pre-service and in-service) want in their classrooms by testing the usability of real tools with participants. Through three design phases, pre and in-service teacher groups informed the design and development of learning tools for social studies DL. Using a Social Construction of Technology lens, I describe the scaffolding embedded in the resulting tool DV4L by considering: 1) teachers’ perceptions of usefulness and usability in the DL tools they explored, and 2) how PD sessions with pre- and in-service teacher groups evolved over time beginning with their interactions with existing tools and leading to our current DV4L prototype tools.
I addressed my second research question through a longitudinal study (Study 2) that delved into how three K-12 social studies teachers explored DL during and after a PLO. Narrative methods were used to describe how three social studies teachers changed their DL practices. The journeys began with teachers as they explored a DL focused PLO, incorporated DL in their lesson plan(s), and include their reflections after implementing the lesson(s) in their classrooms. I used Guskey’s Model for Teacher Change as my analytical lens to understand each teacher’s DL journey.
My experiences in Study 1 and Study 2 made me wonder how expert teachers were meeting their DL learning goals. I used Shulman’s Pedagogical Content Knowledge framework to design Study 3 and address my third research question. I looked at how expert teachers explored DVs and described their DL pedagogical strategies and technology uses through a think aloud and semi-structured interview. Findings describe how five expert teachers made meaning of data and DVs through the practices and strategies they used or described using in their pedagogy.
This dissertation informs the design of curriculum, PLOs, and technology tools to support social studies teachers reach their DL learning goals. It has already informed the design of two socially constructed DL tools for K-12 social studies. Such tools provide teachers pedagogical power in their graphing activities in ways that support their DL learning goals while also promoting engineering skills and thinking.
Do I Have a Say in This, or Has ChatGPT Already Decided for Me?: Guest Blog Post from Aadarsh Padiyath
Hi all! This is Aadarsh Padiyath, a PhD Candidate at the University of Michigan, advised by Barbara Ericson and Mark Guzdial. At ICER and in ACM XRDS this year, I presented research that challenges a pervasive narrative in our field.
In discussions about ChatGPT in computing education, I frequently see claims that “LLMs are here to stay,” from both dejected colleagues and ecstatic researchers… proclamations that we need to “embrace LLMs or face being left behind…” that “since students used ChatGPT they must’ve found it beneficial…” also “Since ChatGPT is free, students will inevitably use it…” and “Prompts First Finally: natural language programming was where we were always headed.”
I see these pieces as exemplifying technological determinism – the belief that technology inevitably shapes society in predictable ways. It’s the reductive “if X, then Y” thinking that assumes new technologies will have predetermined outcomes on our lives and institutions, with humans playing a more passive role – regardless of the countless human choices and social influences that exist.
Our research, presented at ICER 2024, tells a different story. We found ChatGPT adoption in computing education was not a one-time choice nor a foregone conclusion, but an ongoing active negotiation shaped by social factors and individual experiences.
Through surveys, interviews, and midterm performance data from a Python programming course, we found students’ actual use of ChatGPT to challenge determinist narratives:
- Social factors, not just ChatGPT’s capabilities, shape adoption: Students’ perceptions of ChatGPT’s role in their future careers and their beliefs about their peers’ usage (often overestimated) significantly influenced their decisions.
- ChatGPT adoption varies widely – there’s no one-size-fits-all approach: We found diverse approaches, from full embrace to strategic application to complete rejection on moral grounds, often tied to students’ personal learning goals and values.
- Approaches change over time – there’s a feedback loop between ChatGPT use and learning outcomes: Students often initially internalized prevailing determinist narratives, but after experiencing ChatGPT’s impact on their learning (sometimes through receiving helpful guidance and sometimes through a lower midterm performance than they expected) many changed their approach, demonstrating agency and intentionality in their learning process.
These findings challenge the idea that ChatGPT’s impact on CS education is predetermined, LLMs are not necessarily “here to stay.” Instead, they highlight the complex, dynamic relationship between students and this tool.
In light of this, I wrote a XRDS article speaking directly to students about intentionality in their use of ChatGPT. The article encourages students to make active decisions rather than passive ones when incorporating ChatGPT into their learning process. I argue that students should explicitly define their relationship with ChatGPT in their learning process, align their usage with their goals and values, and continually reflect on this relationship. By doing so, they’re less likely to find themselves in unexpected or undesired situations regarding their learning outcomes or skill development.
As educators and researchers, I see our role as helping students make these informed decisions about their relationships with tools like ChatGPT. We need to help students understand the social influences at play, correct misconceptions about ChatGPT’s capabilities and usage, and guide them in aligning their use of tools like ChatGPT with their personal learning goals and values.
By moving beyond deterministic narratives, we can develop more nuanced, student-centered approaches to addressing AI in computing education.For more details on this research and its implications, check out our ICER paper, “Insights from Social Shaping Theory: The Appropriation of Large Language Models in an Undergraduate Programming Course” and my XRDS article “Do I Have a Say in This, or Has ChatGPT Already Decided for Me?”
For the reasons liberal arts and sciences majors should learn to program, AI’s not really that big a deal
“It’s the end of Computer Programming as We Know It” wrote Farad Manjoo in the NYTimes last June.
Jensen Huang, CEO of Nvidia, said earlier this year that programming is no longer important:
“It is our job to create computing technology such that nobody has to program. And that the programming language is human,” Jensen Huang told the summit attendees. “Everybody in the world is now a programmer. This is the miracle of artificial intelligence.”
And just this last week, NYtimes asked “Will A.I. Kill Meaningless Jobs? And is that so bad?” And there examples were mostly about…programming.
I read these pieces and saw a narrow definition of programming. They describe coding as a drudgery of carefully transforming requirements into stable, robust applications. But there’s another side of programming — the one that predates the drudgery one. Programming is also a tool to think and learn with.
Back in 2009, I’d written a blog post, “There will always be friction” inspired by an essay by Michael Mateas. I remembered that the argument then was why natural language programming would never quite work (and the argument pretty much still stands). But then I re-read Michael’s essay and realized that he was saying something much deeper than that. He was describing the reasons to program the way that the LSA faculty who talked to our Computing Education Task Force explained how they thought about and used programming.
There are four reasons to learn programming that we heard liberal arts and sciences faculty asking for and which are reflected in Michael’s essay — reasons that ChatGPT don’t change:
- Computational scientists use code as a way to describe models, and they need the exactness and interpretability of code.
- Computational artists need to know code to use it as a medium, in the same way that artists get to know other media (e.g., watercolors, oil painting, sculpture) to develop their skill and their potential to express with the medium.
- Critical computing scholars have to understand code to reason about its effects.
- Software studies scholars study code the way that earlier humanities scholars study text manuscripts, and it’s hard to study something you don’t understand.
I decided to write a Medium essay about those reasons, grounded in Michael’s essay but updated with an AI-framing — see link here. I decided to try Medium for this because it’s a pretty long essay and many subscribers here get these posts via email. I also want to explore other platforms, to see if maybe Medium is better for commenters than WordPress.
There are other reasons that LSA faculty wanted their students to learn programming, but I left out of the essay one other key reason to learn programming that LSA faculty talked to us about: To become a “conversational programmer.”. Some students take programming courses because they want to understand software development as an activity and to improve their communication with professional programmers. LSA faculty liked the idea of “conversational programmer” for their students.
I left it out because that one likely will get changed by ChatGPT, Co-Pilot, and all the other LLMs. If AI changes the task of professional programming, and conversational programmers want to understand professional programming, then yeah, of course, AI is going to change things.
But AI doesn’t change programming for people who want to think with, express with, and reason about code.
Feeds
Recent Posts
- Dr. Tamara Nelson-Fromm defends her dissertation: What Debugging Looks like in Alternative Endpoints
- Creating a measure of Critical Reflection and Agency in Computing
- Seeking K-12 Computing Teachers With Emerging Bilingual students in their classes
- Three stories about how CS is overwhelming, and ideas for how we can do better
- School teachers don't need to recruit students into CS: An alternative model for K-12 computing education
- How scientists learn computing and use LLMs to program: Computing education for scientists and for democracy
- My Favorite ICER 2024 Paper: How Media Artists Teach Computing
- CS doesn’t have a monopoly on computing education: Programming is for everyone
- Designing Courses for Liberal Arts and Sciences Students Contextualized Around Creative Expression and Social Justice: SIGCSE 2025 Experience Report
- How K-12 CS teachers support students for whom English is not their first language
- Media Computation in Python running in Google Colab Notebooks
- Dr. Bahare Naimipour defended her dissertation
- Kids Think Girls Are Worse Than Boys at Computer Science, by Age 6 - blog post from Amber Settle
- Do I Have a Say in This, or Has ChatGPT Already Decided for Me?: Guest Blog Post from Aadarsh Padiyath
- For the reasons liberal arts and sciences majors should learn to program, AI’s not really that big a deal
Blog Stats
- 2,173,027 hits
Top Posts & Pages
- Constructivism vs. Constructivism vs. Constructionism
- The Story of MACOS: How getting curriculum development wrong cost the nation, and how we should do it better
- A Definition of Computational Thinking from Jeannette Wing
- Computer Science was always supposed to be taught to everyone, and it wasn't about getting a job: A historical perspective
- Yup, That's What CS Textbooks Are Like
- There is transfer between programming and other subjects: Skills overlap, but it may not be causal
- Three types of computing education research: for CS, for CS but not professionally, and for everyone
- Learnable Programming: Thinking about Programming Languages and Systems in a New Way
- Ruthe Farmer’s important big idea: The Last Mile Education Fund to increase diversity in STEM
- Digital Literacy vs. Learning to Code: A False Dichotomy
#CS4All Alice APCS assessment BPC broadening participation in computing CE21 Code.org cognitive science computational literacy computational media computational thinking computer science education computer science teachers computing education computing education research computing for all computing for everyone contextualized computing education CS1 CS10K CS:Principles CSEd Week CSLearning4U CSTA curriculum distance education ebooks ECEP economics educational psychology educational technology education research end-user programming engineering education evaluation GaComputes graduate education higher education high school CS ICER image of computer science image of computing Java jobs K-12 K12 learning science learning sciences live coding Logo MediaComp Media Computation MOOCopalypse MOOCs NCWIT NSF peer instruction perception of university programming programming languages public policy Python robots science education Scratch SIGCSE STEM teachers teaching undergraduate undergraduate education undergraduate enrollment undergraduates women in computing
ComputingEd RSS
CS Teaching Tips
Browse More Teaching Tips
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
Computing Ed Research - Guzdial's Take 
Recent Comments