4. Dijkstra, E. W. On the cruelty of really teaching
computer science. Commun. ACM 32, 12 (Dec. 1989),
5. Garfinkel, H. Ethnomethodology’s Program: Working
Out Durkheim’s Aphorism. Rowman & Littlefield,
Lanham, MD, 2002.
6. Kafai, Y.B. From computational thinking to
computational participation in K- 12 education.
Commun. ACM 59, 8 (Aug. 2016), 26–27.
7. Mehan, H. Learning Lessons: Social Organization in
the Classroom. Harvard University Press, Cambridge,
8. Miller, C.S. Metonymy and reference-point errors in
novice programming. Computer Science Education 24,
2–3 (2014), 123–152.
9. Murphy, L., Fitzgerald, S., Hanks, B., and McCauley, R.
Pair debugging: A transactive discourse analysis. In
Proceedings of the Sixth International Workshop on
Computing Education Research, 2010, 51–58.
10. Roth, W.-M. and Jornet, A.G. Situated cognition.
WIREs Cognitive Science 4 (2013), 463–478.
11. Roth, W.-M. and Lee, Y.-J. Vygotsky’s neglected
legacy: Cultural-historical activity theory. Review of
Educational Research 77, 2 (2007), 186–232.
12. Roth, W.-M. and Radford, L. Re/thinking the zone of
proximal development (symmetrically). Mind Culture
and Activity 17, 4 (2010), 299–307.
13. Shulman, L. Signature pedagogies in the professions.
Daedalus 134, 3 (2005), 52–59.
14. Spohrer, J.C. and Soloway, E. Novice mistakes: Are
the folk wisdoms correct? In Studying the Novice
Programmer, J.C. Spohrer and E. Soloway, Eds.
Lawrence Erlbaum, Hillsdale, NJ, 1989, 401–416.
15. Teasley, S. Talking about reasoning: How important
is the peer in peer collaboration? In Perspectives on
Socially Shared Cognition, L. Resnick, J. Levine, and
S. Teasley, Eds. American Psychological Association,
Washington D.C., 1991, 361–384.
16. Tenenberg, J. and Maria Knobelsdorf, M. Out of our
minds: A review of sociocultural cognition theory.
Computer Science Education 24, 1 (2014), 1–24.
17. Turkle, S. and Papert, S. Epistemological pluralism and
the revaluation of the concrete. In Constructionism, I.
Harel and S. Papert, Eds. Ablex Publishing Company,
Nor wood, NJ, 1991.
18. Wittgenstein, L. Philosophical Investigations /
Philosophische Untersuchungen. Blackwell, Oxford,
U. K., 1997.
Josh Tenenberg ( email@example.com) is a professor in the
Institute of Technology at the University of Washington,
Tacoma, WA, USA.
Wolff-Michael Roth ( firstname.lastname@example.org) is Lansdowne
Professor of Applied Cognitive Science in the Faculty of
Education at the University of Victoria, British Columbia,
Donald Chinn ( email@example.com) is an associate professor
in the Institute of Technology at the University of
Washington Tacoma, WA, USA.
Alfredo Jornet ( firstname.lastname@example.org) is a postdoctoral
researcher in the Department of Education at the
University of Oslo, Oslo, Norway.
David Socha ( email@example.com) is an associate professor
in the School of Science, Technology, Engineering and
Mathematics at the University of Washington Bothell,
Bothell, WA, USA.
Skip Walter ( firstname.lastname@example.org) is the chief
product officer of the FTI Consulting Technology Segment
in Seattle, WA, USA.
Copyright held by the authors.
Publication rights licensed to ACM. $15.00
than the code that is written. Looking
at the code in Figure 1 and Figure 2,
there is little that distinguishes them
from one another. Yet the work that
characterizes joint code writing (
Figure 2) but not teacher presentation
(Figure 1) is in the student offerings of
code that are rejected and the teacher
rationales for the rejections. It is in
that joint work that opportunities for
learning computing praxis, the actual
doing of it, exist. Yet in the classroom
studied—we suspect in most classrooms where joint code writing occurs—no persistent traces (such as
in the form of documents) are made
by the teacher of this most important
feature of the joint code writing. What
students themselves are writing cannot be discerned from the video recordings. But what is clear is that more
students are writing more of the time
after the teacher writes code on the
board than after the teacher provides
a reason for rejecting a student offer
and does no writing, as evidenced in
In noting this key feature of joint
code writing, it can more easily be
made salient to new teachers of pro-
gramming, so the learn-ability of
these moments may be made more
explicit in the teaching practice. We
hyphenate learn-ability to highlight
that in these moments the very abil-
ity for learning is in the visibility of
the practice as it is being constituted
by those present. It is easy for teach-
ers and students alike to become fix-
ated on the end product, the final
code, making such code the sole fo-
cus of instruction, all the while los-
ing sight of the accounts that experi-
enced programmers can, but not
necessarily will, provide for all of the
wrong turns novices inevitably make
as they struggle to develop a pro-
gram for a given problem. In addi-
tion, to support learn-ability in this
pedagogical praxis, these rules of re-
jection are likely to be at least as im-
portant to preserve in some persis-
tent form as the code itself, whether
as written annotations to the code, a
table to summarize the joint work,
or some other form. And for this
task, it is possible that new techno-
logical tools can also be employed,
such as the teacher using a group-
editable document like a Google
Docs document for writing the code,
where the students, in real time and
in full view of one another, provide
the reasons for rejection as com-
ments within the document.
It is easy to view code as a purely
formal object and conceive of its pro-
duction as a straightforward matter
of applying generative rules and rou-
tines to produce correct code to spec-
ification. With such a perspective, we
can study expert behavior in isola-
tion to try to determine such rules
and routines and then seek in novic-
es those deviations and missteps
that lead them to failure. Here, we
have taken a different perspective,
inquiring into the actual work stu-
dents and teachers do together in a
signature pedagogy of the program-
In examining an episode of joint code
writing as a social accomplishment, we
find what has been hiding in plain sight
but viewed as unremarkable and hence
unremarked upon in the literature. The
rules for rejection of code are as important as the generative rules and routines
for producing correct code, since the
space of incorrect code is vastly larger
than the space of correct code. What
might be viewed as failure on the part of
students who offer pieces of code that
are rejected can instead be seen as learn-able moments, at least as productive as
those offers of their code judged correct.
This pedagogical form makes explicit
the reasons for rejection that so many
other pedagogical forms leave unexplained. In so doing, it makes the instructor’s cultural knowledge explicit
and visible to students at a particular
point in time.
We wish to thank Natalie Jolly for
reading early drafts of this article and
the Helen Riaboff Whiteley Center of
the Friday Harbor Laboratories of the
University of Washington for providing a facilitative writing environment
as we completed an early draft.
1. Collins, A., Seely Brown, J., and Holum, A. Cognitive
apprenticeship: Making thinking visible. American
Education 15, 3 (1991), 6–11.
2. Cooper, S., Grover, S. Guzdial, M., and Beth Simon, B.
A future for computing education research. Commun.
ACM 57, 11 (Nov. 2014), 34–36.
3. Crouch, C. and Mazur, E. Peer instruction: 10 years of
experience. American Journal of Physics 69, 9 (2001),