On pacing and programming pedagogy
I’ve been reflecting a lot lately on how I learned to code. I’ve lamented how complicated programming systems have become; I’ve pondered the half-life of technical knowledge; I’ve given talks on how my unexpected path to computing was through a simple battery-powered graphing calculator that fit in my pocket. The pervasive them of all of these reflections is that learning about computing is perhaps more a product of circumstance than personality.
But there is one aspect of circumstance that I’ve been thinking a lot about lately: the pace at which one learns programming. From one perspective, pacing seems like an inane concern. Imagine a software engineer first learning a complex web service and API like Firebase being told “You have precisely 4 weeks to master it or we will label you a failure.” Or a senior architect who has long worked in C++ learning Rust being told that “You have 2 weeks to reach fluency or you lose your job.” Or a musician picking up Sonic Pi trying out live coding performances being told by the software, “If you make too many syntax errors, I will revoke your license and force you to pay again.” These kinds of arbitrary timelines for learning make no sense in practical contexts of creativity and engineering.
And yet, in higher education, we regularly impose such timelines on students. In an intro programming course, we say, “You have one week to learn if statements, and if you do not, you will fail the midterm and be forced to delay graduation or leave the discipline.” Or, we say “You have 15 weeks to become a competent algorithmicist, and if you do not, you will be shamed by your parents and peers and be forced to drop out.” These kinds of inhumane timelines are treated as normal by many higher education faculty as normal; some even frame them as tests of who the “real” programmers are, as if there is some biological predisposition to learning at an arbitrary pace with little support or feedback. While students often accept these authoritative decrees, they know at some level that they are ridiculous, unfair, and brutal.
When I think back to the pace of my learning, it’s hard to even define. I first stumbled into programming with my TI-82 graphing calculator, captivated by a version of Tetris a classmate had shared from his brother. As a closeted, awkward, shy trans middle school girl, I split my time after school between homework, basketball with friends, and reading the code for this Tetris game and the TI-82 graphing calculator over, and over, and over. If I remember correctly, I studied that one program and the many words in the manual on TI-BASIC for maybe 6–9 months off and on. There was no supervision; no teacher was evaluating my learning; there were no tests, assignments, quizzes, or labs. All I had was a personal goal: make Tetris playable on my calculator.
My learning progressed in fits. I remember learning GOTO first, realizing that each line number had meaning and that the GOTOs determined the order in which instructions executed. I made big maps in paper journals of where the GOTOs when, slowly comprehending the different sections of the thousands of lines in the program. That intricate map, in my head and on paper, was my guide to the rest of the language, as I slowly picked up what a variable was, what a loop was, and how the various cryptic functions were responsible for drawing pixels to the plot to make up a Tetromino. Syntax was probably the last thing I learned, since so much of my time was spent simply reading the program. It was months before I ever tried editing it, as I was intensely afraid of breaking it and never being able to repair it. Throughout, worn pages of my calculator’s manual were my teacher, helping ground the examples in the Tetris code with the examples in the manual.
Months later, when I made my first edit, it was exhilarating: even simple one line changes had profound impact on the behavior of the game, and I began to see how I might plan multiple lines of changes to achieve my goal. Much of my attention went to the rendering part of the game, which was the obvious source of its slowness, as I could see pieces slowly erase and redraw, one line down at a time. I remember making my own small program to try drawing Tetrominos in different ways, and through lots of tinkering in safer sandboxes, discovering that the text console rendering was much faster. I began to sketch out a different way of rendering the pieces. Perhaps six months after I first started reading the program, I began to change it purposefully, and converge toward a better design.
In all, I probably didn’t spend more time on this side project that I might have in a semester long course. But the order in which I did things, the pace at which I did them, the criteria by which I governed my progress, and the ways that I let my curiosity drive everything, where nothing like most higher education programming courses. My learning trajectory was structured around me, in a radically culturally responsive way.
None of this is to glamorize autodidactic learning. I desperately wanted a teacher the entire time, someone to just explain to me the cryptic ideas I was encountering, to help me when I got stuck, to help me see the bigger picture while I was stuck in the weeds of a missing parenthesis. A teacher would have transformed my 6–9 month project into a joyful six week jaunt. The only thing intrinsically valuable about my self-guided learning was that I had agency in structuring my learning. This student-centeredness does not require the absence of teachers; it just requires teachers to be student centered.
When we look at higher education programming pedagogy, and its strict, unrelenting pace, its hard to see any room for agency. Some mastery learning approaches, like the ones my colleagues Brett Wortzman and Kevin Lin have been exploring, make strides toward student agency. But even then, the broader structures are intact: the grades drive behavior, the 10 week quarter drives the pace. The persistent industrialization of learning, long built into the foundation of higher education, is hard to root out with half measures, despite my colleagues’ heroic and ambitious restructurings. And so pacing continues to reign over student needs.
As a Professor in an Information School, I do not have the privilege of teaching introductory programming courses or defining computing curricula. My purview is over information curricula, which only obliquely intersects with programming. But if I did, this is what I would try:
- I would have two entire years of lightly scaffolded project-based learning about programming. Whether quarters or semesters, every student would enroll in the same course — let’s call it CS 1 Programming. It would be graded credit/no credit and span roughly 15 hours a week.
- Direct instruction would include a collection of resources for learning, especially textbooks and carefully curated videos. Students would use them when they need them, pointed to them by instructors when a student encounters the need to learn a concept. Class time would be studio time, to help organize community, connect students with resources, and scope projects, much like a shop class.
- Assessment would be based on badges, spanning hundreds of different small units of knowledge, including everything from particular syntax and semantics in particular language, to ideas in algorithms and data structures, and specific technologies for particular domains. Instructors would assess students for badges through conversation, with students showing what they’ve learned, celebrating their work, and instructors deeming whether they’d mastered the concept. Earning badges would not be required at all; they would simply be a personal tool for students to mark, celebrate, and share their progress, and gain confidence in their understanding.
- After two years, students would have access to a broad collection of advanced topics, as is currently offered in higher education curriculum, building upon two years of student-led programming practice. The courses would indicate what badges would be most helpful to thriving in the course, kind of like prerequisites, but students would be free to enroll without having met them, picking up skills along the way.
- Throughout these two years, the role of instructors and TAs would primarily be that of tutors, helping students select direct instruction, helping them learn concepts in the context of their projects, formatively assessing their knowledge through earning badges, and helping grow their interests, self-efficacy, courage, and identity as programmers. Of course, peers would all play these roles as well, helping students learn in the same ways, and through the process of teaching, learning themselves.
- During these two years, students would take the rest of their general education requirements in humanities and social sciences, giving them critical perspectives on their creative making. Throughout, these courses would help complement students’ creative tinkering with persistent questions about why they are making what they are making.
- At the end of the two years, students would celebrate their learning by demonstrating what they created, chronicling their learning, sharing their earned badges, and thanking the many friends, peers, TAs, and instructors for helping them on their journey. Such celebrations would happen at the end of quarters/semesters, so that newcomers would be able to see and celebrate their peers’ “graduations” from the course and imagine themselves in a similar place in a couple years.
This vision draws from many scholarly ideas, including culturally-responsive computing, mastery learning, connected learning, and constructionism. But it also derives from much older traditions of apprenticing, in which people learn by doing, but under the supervision of a community of practitioners who can guide and teach on-demand. These powerful ideas are far more proven and grounded in education research than the current pedagogy, which largely derives not from learning science, but capitalism, industrialization, and statistics.
Does anyone want to hire me to build out this vision for their program? I’ll do it! It will be awesome and beautiful and inclusive and transformative and it will be the envy of all of academia globally. Philanthropists will shower money upon your school, not only for its innovation but for its outstanding, confident graduates. No? Okay. Does anyone want to try it themselves? Not up for the fight with your colleagues you say? Afraid to take the risk? Hm. Okay. In that case, let’s keep tinkering with the low order bits of programming pedagogy for another three decades and see how far it gets us. I have my predictions :)
More seriously, change is hard. I get it. Thinking in radically different ways about teaching and learning is scary and implementing them is even scarier. And rarely are we given the resources to actually plan such changes. But we have to think more courageously. The systems we have now are not serving students or the world and we must change them.
