A photograph of the book over showing a robotic butterfly and the book title, blurred in the background.
282 pages of CS education research and practice, alphabetized.

A Review of Computer Science in K-12, An A to Z Handbook on Teaching Programming

Amy J. Ko
Bits and Behavior
Published in
8 min readFeb 1, 2021

--

I don’t know if you’ve heard, but teaching computer science is hard. Code can be unforgiving; students find their ways into dark corners of languages and tools, and if teachers don’t know how to help students out of them, students might lose faith that they can learn CS, and lose faith that teachers can help them. Engaging students in making anything remotely interesting can be challenging in all but the most carefully controlled settings, and even then, teachers need a rich toolbox of pedagogical content knowledge (PCK) for managing the inevitable complexity of student identities, interests, and strategies. And if a teacher wants to support and engage every student in a way that helps them develop identity and self-efficacy in CS, while also developing their critical consciousness about computing and society, teachers need more than PCK— they need curricula, frameworks, and ever evolving knowledge to structure and guide their teaching over time.

A key resource for helping CS teachers develop their knowledge are books that teach this CS PCK. And there are more books than ever:

With so many books covering so much ground for K-12 CS education, it’s hard to imagine that more books would be helpful. However, Shuchi Grover’s recently released edited book Computer Science in K-12: An A to Z Handbook on Teaching Programming, shows that there’s much more to add, especially from the wealth of recent research on K-12 CS education.

The book, like most edited volumes, presents a diversity of perspectives and voices, with 26 chapters and 39 contributors spanning all areas of CS education expertise. Shuchi, a CS education expert herself, had the immense responsibility of wrangling 39 very busy people to share their expertise in a way that was grounded in both practice and research, but also accessible to busy teachers. It therefore has a curious structure: rather than sequencing the book by CS concepts or methods, it’s sequenced alphabetically: it starts with algorithms and planning, sprinkles some creativity, data structures, and events, then winds through feedback, unplugged activities. Project-based learning appears throughout the book, and basic concepts in programming languages like expressions, repetition, and variables appear scattered throughout. There is order to this—the preface gives an alternate ordering of chapters by concepts, practices, and pedagogy, and even guides some helpful tips about various orders it might be read it—but ultimately, as an edited book, the only way to absorb the breadth of its insights is to read it in entirety.

So that’s what I did. Rather than treating it like I might other non-fiction I’ve read recently, where the goal is to deeply comprehend an argument, I read A-Z like the book recommended for teachers new to CS: from cover to cover, once chapter each Monday through Thursday morning across two months, much like a teacher might do amidst a busy school year. The experience was surreal in some ways: because chapters often overlap in their ideas, I sometimes experienced déjà vu, and had to return to previous chapters to stitch together implied links. In other ways, the experience was very concrete: many chapters provide very precise examples about how to teach particular concepts, and I found myself pouring over example materials, trying to connect the examples to the theories and frameworks chapters presented. This is no recipe book—it requires active effort on the part of a teacher to synthesize and apply to lesson planning—but it does provide enough examples to position a teacher to do that work.

Many chapters were impressively focused. The Peer Collaboration and Pair Programming chapter (P!), for example, provided an exceptional definition of pair programming as a programming strategy and pedagogy, gave lucid instructions around how to pair students, define roles, and structure activities, and provided some very enlightening pedagogical content knowledge for distinguishing between collaborative and non-collaborative pairs, and how to intervene to resolve conflicts, power struggles, and disengagement. This chapter, more than most, felt like the best balance between theory and practice (though many other chapters, such as Questions and Inquiry, Variables, and Physical Computing were also really nice).

While all of the chapters felt well-grounded in research and helpful in practice, this does lead to some sacrifices in precision data structures, algorithms, and programming languages concepts. The descriptions of algorithms, events, functions, expressions do not get into the precise semantics of program execution, and therefore do not do much to demystify how programs work. But the medley of heuristics and conceptual descriptions likely provide a reasonable scaffolding for teachers just developing their CS content knowledge. This seems like a reasonable tradeoff for the book’s goals, but teachers will likely need to look elsewhere to develop more a robust understanding of programming languages.

Another omission was critical perspectives on computation. I appreciate the constructionist traditions that the book builds upon, which often frame code as a medium for creative expression, and the commitments throughout the book to inclusive pedagogy are clear. There unfortunately few mentions how code centralizes power, it dehumanizes process, and it encodes discrimination and bias in subtle but destructive ways. I hope other books will contribute more narratives on computing, complementing this book’s skill-based pedagogical focus.

Despite these few omissions, the book is an essential read for K-12 CS teachers. Back in 2010, I remember asking my colleague Mark Guzdial over email, “How can we best teach variables?” and he said something to the effect of, “To be honest, we really don’t know.” This book shows that we actually do know enough know enough to provide some helpful guidance. And when my many other colleagues now ask me the same question, I have a chapter I can point them to.

While the book has a printed order, and a preface that recommends other orders, for teachers new to programming and to teaching CS, based on m lab’s research on teaching programming (e.g., Nelson et al., 2017, Xie et al, 2019), I would actually read it in this order:

Diversity

I recommend first starting with essential principles that teachers should follow when teaching programming:

  • Universal Design for Learning. This chapter establishes the fact of learner diversity, reminding teachers that reaching everyone requires a diversity of methods and careful choices about tools and programming languages.
  • Learner-Centered and Culturally Relevant Pedagogy and Zestful Learning both provide an essential reminder that no matter how one teaches, if learners aren’t enjoying it, and don’t see a way to connect their identity, interest, and values to the material, it doesn’t really matter how effective a teaching method is in isolation.

Programming languages

After setting the stage with diversity, next I would read about programming language concepts in an order typically followed to construct a basic interactive, event-based program that responds to user input:

  • To start, I’d recommend reading JavaScript, Python, Scratch, Or Something Else? Navigating the Bustling World of Introductory Programming Languages, since it demystifies the diversity of languages, and shows that they often overlap in some conceptual ways. Starting here can help limit the threat imposed by the diversity of languages that appear in other chapters.
  • Events come next because they are most typically the entry point into a program responding to user input in most languages used in K-12.
  • Variables comes next, as they are the building block for enabling programs to express conditional behavior in response to user input.
  • Operators and Expressions are essential to building conditional logic, and often use variables.
  • Selection With Conditionals builds upon Variables and Operators and Expressions, demonstrating how to use those language features to alter program behavior based on user input.
  • Repetition and Recursion comes next, because most programs written in K-12 require this to do something interesting with conditional logic.

Abstraction

After covering the most basic elements of imperative programs, only then would I recommend reading about the central mechanisms of abstraction in programming languages:

  • Data Structures provides an important foundation for processing lists of data.
  • Once data structures are clear, Algorithms can come next, because it demonstrates how one might use data structures and all of the other language features to abstractly reason about data.
  • Only after Data Structures and Algorithms are clear does it make sense to discuss Modularity with Methods and Functions, since procedural abstractions are simply ways of reusing those ideas.
  • Naive Conceptions of Novice Programmers comes after all of the other programming language concepts, because the reader needs to know those concepts before understanding how learners might misunderstand them. It might also correct misunderstandings the reader has.

Programming

After covering programming language foundations, then it makes sense to discuss programming as a process:

  • Knowledge, Skills, Attitudes, and Beliefs: Learning Goals for Introductory Programming is a great place to start, since it defines the many skills involved in programming, and the critical role of mindset and self-efficacy in learning those skills.
  • Before You Program, Plan! comes first, because it reinforces that programming is a process, and that programming language knowledge is just a prerequisite to orchestrating that process.
  • Testing and Debugging comes next, because the first line of code anyone writes is going to be defective :)
  • Yay, My Program Works! Beyond Working Code… Good Habits of Programming provides some additional testing advice, as well as indirectly addressing code style problems that might signals naive conceptions of a programming language.
  • Peer Collaboration and Pair Programming is a great chapter to end with, because it demonstrates a programming process that can help scaffold all of the skills discussed in the chapters above.

Scaffolding

As I noted at the beginning of this post, programming is hard, and so learning all of the skills above requires immense scaffolding. These chapters do a great job of illustrating scaffolding techniques:

  • I like starting with Feedback with Formative Check-Ins, because it reinforces that languages and programming are skills that require a lot of time and refinement to learn. Formative assessment is therefore key.
  • After covering formative assessment, Worked Examples and Other Scaffolding Strategies, Guided Exploration with Unplugged Activities, and Questions and Inquiry provides a nice collection of generic concepts and techniques for scaffolding teaching programming.
  • The four remaining chapters, X-ing Boundaries With Physical Computing, Creative Coding, Hard Fun with Hands-On Constructionist Project-Based Learning, and Integrating Programming Into Other Subjects all present nice frameworks to scaffold a teacher’s unit planning around projects and particular domains.

While the book could have done more—as is true for any book—I heartily recommend it. I think it’s a notable exemplar for blending research and practice. And as the sequence above shows, it’s a really versatile book, which can be used in many different ways. I hope others will read it and share other ways they might sequence and use the book to support teacher learning!

--

--

Amy J. Ko
Bits and Behavior

Professor, University of Washington iSchool (she/her). Code, learning, design, justice. Trans, queer, parent, and lover of learning.