Teaching Python: Part 1
This is part 1 of a series of posts about rethinking and redesigning introductory Python teaching materials.
Learning to teach coding
In January 2025, I’m going to present a lightning talk at the Teaching Coding Across Disciplines Winter School in Edinburgh. My brief talk is very heavily inspired by my recent reading of the (excellent) book Data Feminism (D’Ignazio and Klein 2020): this book articulated feelings that I’d had for years but didn’t know how to state coherently, and also confronted me with deep-seated misconceptions I didn’t even realise I held.
My experience learning coding
The entire way through University, I really enjoyed some maths tutorials, and absolutely hated others. The ones I woke up with dread to face involved working on problems in the class, or working as a group solving maths problems. The ones I enjoyed gave me homework beforehand, and involved meeting in the tutorial to discuss the answers. I really struggled with every coding lesson I did that involved live coding or pair programming; I quickly fell behind, became completely lost, and at some point switched off and just accepted that I would figure it out myself later. I assumed that it was my inherent lack of ability: some people seemed to thrive under these settings, whereas I clammed up - this was obviously my fault; I wasn’t suited to the subject matter; I was out of my depth.
Live coding is still actively encouraged by Software Carpentries and widely held up as the default best way to teach. I cannot explain how viscerally I have hated every live coding session I have ever attended as a student: I have felt immediately under time pressure, have not been able to take notes, and spend the session essentially just frantically transcribing the teacher’s code with not an ounce of reflection or absorption of the information. This mismatch between my abilities compounded my feelings about undergraduate: I was one of the very few women in my large physics degree, and I was one of a tiny pool receiving a full means-based fee waiver and maintenance grant to attend my prestigious university. I already didn’t fit in, and I was obviously just not able to handle the fast-paced technical teaching style of sessions where I was under time pressure and had to actively produce code under pressure.
A different view?
Later on, having specifically left physics because I believed I wasn’t capable (hilarious that I ended up doing a PhD that involved computational modelling of thermodynamic processes on a supercomputer), I ended up hearing my own experiences echoed back to me by colleagues, primarily women colleagues. This rejection of live coding as an encouraging introduction to coding seemed to pervade across attendees of training events, in sharp contrast to those who delivered such events. I ended up going down a bit of a rabbit hole in regards to pedagogical methods in coding teaching practice, and found an entire world of rich methods that diverge from live coding as the be-all and end-all. In fact, some studies suggest it’s not particularly effective, or at least no more effective than other methods (Shah et al. 2023).
Teaching differently
After reading Data Feminism, I began to think more about how assumptions about how we best learn to code systemically excludes groups. I have some processing delays that make it so there’s a slight lag between me hearing/seeing something and actually comprehending it. As I said, for me this is a slight effect, that on a day-to-day basis means I often interrupt people asking “what?” as though I haven’t heard them, only for my brain to catch-up and actually process what they’ve said before they repeat themselves. In live coding sessions, it’s a nightmare, regardless of how slowly the teacher moves.
While I like the idea behind the traffic-light post-it-note system to help students flag when the session is moving too fast, I also have to again look at my own personal experience of this. Yes, it’s less intimidating to stick up a post-it-note than to raise your hand and ask for the class to slow down, but in live-coding environments I already felt behind and a poor fit for the session, I absolutely did not want the class to have to slow down on my behalf. At some other point in time I will write a post describing my issues with the victim-blaming mentality of the concept of imposter syndrome (way to make a toxic and uninviting workplace the fault of the person experiencing exclusion), but I don’t think we can understate the levels of anxiety people can feel about impacting others in a space where they feel they don’t belong (or in a space where they are actively made to feel they don’t belong because of their membership of a minoritised group).
I’m currently redesigning an introductory Python course that leans heavily on flipped learning models and alternative teaching techniques (Fabic, Mitrovic, and Neshatian 2018; Williams 2022; Gan and Ouh 2022), and will be discussing this process alongside my experience of learning to code in my talk at the aforementioned winter school/conference. As I’m a relative newcomer to this entire field, I’m really excited to listen and learn from the other speakers.
Condensing these thoughts into a talk
Here’s my talk title and abstract:
Coding by whom? Coding for whom? Coding with whose interests in mind?
Research computing competency and specifically programming skills are becoming ever more important in our data-driven world: Jacobs et al. (2016) argues that “we are rapidly approaching a point where innovations [in research] will primarily come from those who are able to translate an idea into an algorithm, and then into computer code.” With the proliferation of algorithmic approaches in every aspect in our lives (not just in research methods), it is ever more important to strive for justice and equity in programming education. According to the UK Government Digital Strategy policy paper, despite women making up almost half of the workforce, we are under-represented in the tech sector: just 17% of people who work in the tech sector and only 9.5% of students taking computer science A level courses are women (“Digital skills and inclusion - giving everyone access to the digital skills they need,” n.d.). This glaring disparity is also apparent for other minoritised groups, and is compounded for women of colour (Cook 2021).
As D’Ignazio and Klein (2020) succinctly state in the opening of their book Data Feminism, “Data science by whom? Data science for whom? Data science with whose interests in mind?”, this inequity has far-reaching impacts on society. In the context of teaching coding, how do currently accepted practices reinforce and uphold unjust power structures? How can we use our varied institutional power to work towards justice in digital skills? Education can both be a mechanism for empowerment and transformation (D’Ignazio and Klein 2020) or can serve to compound existing inequities (Collis 1985). In this talk, I combine reviews of teaching practices (Campbell et al. 2024; Jacobs et al. 2016; Alammary 2019), studies and projects using alternative teaching methods (Fabic, Mitrovic, and Neshatian 2018; Williams 2022; Gan and Ouh 2022; “Code4000” 2022), and personal experience in learning, teaching, and developing educational materials. I hope to prompt an on-going discussion on equitable teaching practices in programming!
References
Citation
@online{murphy_quinlan2024,
author = {Murphy Quinlan, Maeve},
title = {Teaching {Python:} {Part} 1},
date = {2024-12-20},
url = {https://murphyqm.github.io/posts/2024-12-20-teaching-python},
langid = {en}
}