Communications of the ACM
Home/Magazine Archive/May 2018 (Vol. 61, No. 5)/More Than the Code: Learning Rules of Rejection in.../Full Text
Contributed articles
More Than the Code: Learning Rules of Rejection in Writing Programs
Credit: Kostsov
Lee Shulman, a past president of the Carnegie Foundation for the Advancement of Learning, identifies the signature pedagogies of professions as those characteristic forms of teaching and learning that "define what counts as knowledge in a field and how things become known."13 If there is a signature pedagogy for computing, it is surely the writing of code together between a teacher and students: The teacher poses a problem, solicits input from students about how to write the code to solve this problem, and weaves together the suggestions from different students into a coherent whole. This pattern is so pervasive that anyone who has spent time in a computer science classroom has participated in this pedagogical form.
Key Insights
Given its ubiquity, one would think this signature pedagogy is well understood. Yet our search of the educational literature yielded not a single prior research study focused on this signature pedagogy of computer science. Our aim here is to fill this gap. In particular, we provide an empirical account of the joint—irreducibly social—work that programming students and teachers perform. We ask: What is it that occurs when a teacher and students write code together? What is learn-able about that joint work? And how can it further inform computing teaching and learning practice?
Programming as a Social Practice
In addressing these questions, our study approaches programming as a social practice. Almost 30 years ago, Sherry Turkle and Seymour Papert17 described the common conception of programming as one that is fundamentally formal: "The prevailing image of the computer is that of a logical machine, and . . . programming is seen as a technical and mathematical activity." No one represents this view better than Edsger Dijkstra,4 who described programs as "rather elaborate formulae from some formal system" and "an abstract symbol manipulator which can be turned into a concrete one by supplying a computer to it." Accordingly, the activity of programming is a technical exercise of the individual programmer who produces a correct program from a specification. According to this view, it is unsurprising that much computing education research has been devoted to categorizing and quantifying student errors and mis-conceptions in comparison to the "correct," or canonical, behavior of experts in carrying out this formal activity.8,14
Over the past several years, however, a different view of programming has emerged, one that sees programming as inherently social. In a 2016 Communications article, Kafai6 states that "[c]oding was once a solitary, tool-based activity. Now it is becoming a shared social practice. Participation spurred by open software environments and mutual enthusiasm shifts attention from programming tools to designing and supporting communities of learners." This shift of attention from the isolated individual to participation in social practice has led to considerable research advances in the educational literature over the past several decades.10,11,16 Research in computing education is beginning to appear that draws on sociocultural theories of cognition and learning and their methods of empirical investigation. This is consistent with a 2014 report,2 which states that "many questions [in computing education] remain unanswered and would benefit from contemporary research in the learning sciences in sociocultural and situated learning, distributed and embodied cognition, as well as activity, interaction and discourse analysis."2 It is in this gap in the literature on the social practices within computing classrooms that this study is situated. An important question to consider, then, is: What does it mean for a practice to be social rather than individual? A practice is social because practitioners act as if they were following specific rules of the game, and an observer can read these rules off from the practice of the game even if the players never articulated or are aware of the rules.18 It is with this definition of social practice as the joint work of making rules present in and through practice that we turn to an analysis of joint code writing.
Analysis of a Joint Code-Writing Episode
To illustrate how learning to program can be approached as social practice, and how such an approach can be relevant to computing education, we present and analyze an episode from a data structures course taught at a small private university in the U.S. The episode has been culled from a database that includes video recordings, photographs, ethnographic observations, and interviews from the entire course, which met for 50 minutes three times per week over a 15-week term. The students and teacher also met for an additional session each week for two hours in a large computer laboratory. Audio-visual recordings were made in both settings from two cameras placed on a ceiling-mounted overhead projector in the center of the room, one pointing to the front of the room and one pointing to the side, augmented by and later synchronized with audio recorders placed around the room.
Chalk and talk. The episode begins 21 minutes into a class session during the second week of the term. In attendance are 30 students occupying most of the 37 seats in the room. The teacher, Alan (a pseudonym), is in his fifth year of teaching in higher education, doing the data structures course for the third time. Alan stands at the front of the classroom, in front of a blackboard of three equal sections that spans the entire front wall. He begins the episode saying,a "So the question is (0.4) how do you make something like this (1.6) if you were to code up your own ArrayList (0.5) which incidentally is this week's homework assignment (2.9) how would you do it (2.8) now one approach you could do [Erases center board, writes 'class MyArrayList {'at the top of this section]."
Alan makes two statements that have the syntactic form of questions. Yet in neither case does a student respond. For the second question, Alan responds to his own question and begins a presentation that lasts almost nine minutes, with only two students speaking during that time for a total of less than 20 seconds. Code is presented as a fait accompli, a rationale preceding each line of code (such as "because constructors have no return types"). The teacher speaks and writes, whereas the students align their bodies and gaze in the direction of the teacher and what he is writing on the board, occasionally looking down to their desks as they write notes. Figure 1 shows the final code filling the blackboard's center section at the end of this chalk-and-talk session of nine minutes, 10 seconds. This session, in which the teacher writes while providing extensive verbal accounts, is typical of most of the class sessions recorded.
Figure 1. Presented code from first part of the episode.
Thus far, there is little that might be thought of as the collective writing of code that includes students as well as the teacher. Alan's next statement appears to be more of the same. He stands in front of the code he has just produced, faces the class, and says, "all right (0.3) how would I create an add method (6.8) I want to add a new object to myArrayList how would I do that (4.2)." There are several pauses during this turn, and two statements that have the grammatical form of a question ("how would I"). As the pause extends at the end of this statement, it affords room for anyone to speak, and the shape of the discussion will be determined by what the actors in the setting actually do. It is not clear at this point what constitutes an appropriate response or who should provide it. For example, it may be another rhetorical question to be answered by the teacher. It is only in their unscripted and irreducibly social transactions that the teacher and the students together work out what this lesson is to be as it unfolds.
Participative code writing. A significant shift in the lesson occurs when the silence at the end of Alan's utterance is broken. A student says, "well you're going to want your add [Alan turns toward board] (0.4) uh method [Alan starts walking to right-hand third of the blackboard] to be public so you're going to want some javadoc," followed by Alan saying "right" and writing "// javadoc" at the top of this section of the board. Taken together as a unit, these first three turns at talk may be seen as a variant of what in educational research has become known as the "initiation-response-evaluation" pattern, or IRE.7 In the original version as reported in the literature, the student provides an answer to a query that is then evaluated. But in the variant here, the three-turn sequence is an initiation to a social practice (here, writing code), an instance of this practice, and feedback as to how well the newcomer has done.12 From the student perspective, these are first instances where they live and indeed partake in such cultural practices as writing code. Cultural practices and the languages that go with them have been called "language games."18 Ludwig Wittgenstein insists on the fact that language games may be learned before and sometimes "without ever learning or formulating rules." Any game may be learned by participating in it and then being told a rule as part of feedback on why a move does not work. In this case, "the rule may be an aid in teaching the game." In saying "right," Alan makes it evident for everyone to see that the student has acted in a way that is consistent with the cultural rules of writing code, without those rules being explicitly stated in advance.
In the next turn-pair, a student says, "and (0.4) uh it's going to need to take an argument" after which Alan writes the word "public" on the next line on the blackboard. This turn-pair can be seen as the response-evaluation part of the IRE pattern, with the initiation—the "I" part—implicit in the evaluation—the "E" part—of the prior IRE. But it is only with this new student response and teacher evaluation that the teacher's evaluation in the prior IRE can be seen as initiating the response and evaluation that follow. That is, this IRE speech pattern is neither the teacher's nor the students' alone but is irreducibly spread across them; it is a structure of participation in this game. Only in the student response can the statement preceding and following be seen as initiation and evaluation; and likewise, only in the teacher initiation and evaluation is the student's utterance seen as a response. This pattern of linked, cascading IREs continues through almost all of this eight-minute joint-code-writing episode, with the evaluation part including either an explicit or implicit solicitation for further student response.
In the subsequent turn sequence, the student continues his earlier utterance, saying "which I believe will be an object you could just call it add" and Alan saying "okay (0.5) so I'm going to make public [writes and speaks the following words at the same time] void add [writes '(' ] and it'll [writes 'Object' as he speaks the rest of his turn] take an object what do you want to call that object." Alan's writing and corresponding speech do three things at the same time: acknowledge what the student offered, provide a positive evaluation in the writing, and correct and elaborate what was said while putting it into code. The teacher, in his actual practice, writes what is "right."
Rejection rules. Thus far in this episode, all student moves have been marked as correct, with corresponding writing on the board. The next several turn-pairs reveal what happens when student moves do not follow the rules of the unstated but present game. In the turn just finished, Alan ends with an explicit initiation in the grammatical form of a question, "what do you want to call that object." Another student responds with "uh submit," which is met with no writing and Alan's comment, "submit's a little strange, submit's a verb (2.4) any other ideas for what we what's a good name for this object that we're passing in (2.4) [turns from student to others in class]." Another student says, "my object," which again is not written on the board but is instead given an explanation for the nonacceptance: "eh my object's a little bit too vague."
This code-writing session continues for another 23 turn-pairs, for seven minutes, 40 seconds total, with contributions from eight students; Figure 2 shows the resulting code. Generalizing across all of these response-evaluation pairs in the episode, accepted moves are always translated into correct code and written on the board with no explanation, while rejected moves are (in every case but one) met with explanations for their rejection and not written on the board. We summarize with this simple rule: What is right is written, what is not right is explained.
Figure 2. Final code for add method.
In looking at these explanations for rejection ("submit's a verb," "my object's too vague"), they can be heard as rules that have been violated in the student contribution to the game (writing code), for example, that appropriate identifiers for this parameter should not be a verb, should not be vague. Yet there are qualitatively different kinds of reasons given for rejection from one case to another. Although we do not show the entire transcript here, Table 1 lists various types of reasoning about programs the teacher makes visible in his evaluations of student responses across the entire episode.
Table 1. Classification of rules offered as reasons for rejecting student responses.
These rules evidence Alan's expertise as a computer programmer and as a teacher. He plays his part in what Collins et al.1 call "cognitive apprenticeship," where expertise is made visible in an appropriate context, so students, who are indeed participating in the cognitive practice, can see instances thereof. In this sense, the "rejection rules" Alan makes visible are significantly unlike the kind of accounting students do with one another when they pair-program, where negative criticism and explicit justification are virtually nonexistent.9 And although various other forms of peer learning (such as teamwork, group work in a "flipped" classroom, and Peer Instruction3) often provide "a natural context for elaborating one's own reasoning,"15 they may nonetheless fail to provide a context through which expert reasoning (such as these rejection rules) can be made available to students.
Toward a signature pedagogy. But it would be a mistake to see this making expert work visible as Alan's accomplishment alone, as if Alan is the sole active participant, pouring programmer wisdom into passive student containers. For in the first part of this episode, when Alan was presenting code as something already accomplished and written (Figure 1), he was writing on the board what he was explaining and explaining each statement he wrote; that is, the earlier part of this episode was governed by a different normative rule. And this earlier kind of classroom behavior—this chalk and talk—is so mundane it goes unnoticed as a pedagogical choice, replicated in countless online video tutorials for introductory programmers, with a talking head and a writing hand at the whiteboard, as well as in introductory programming textbooks and the lecture slides that accompany them as canned teacher resources. Only what is correct is given, accompanied by detailed explanation.
In the presentational forms of instruction, the ways a program and writing code can go wrong are missing. However, the ways things can go wrong are even more essential to knowing a practice.5 These ways become apparent in the second part of the episode, where students and teacher together make visible and audible two types of instances. When students' programming moves are appropriate, they are accepted without actually stating the rules, but when the moves are not part of the game, they are rejected and an associated rule is articulated. Here, students are part of playing a game, living the practice of coding; and with some practice, they will be playing the game in its solitaire variant or with other learners outside the classroom. There is a simple but easily overlooked fact about programs for why such rules of rejection might be important to know and share: The number of programs that is not correct—syntactically, semantically, or pragmatically—for any given problem is far, far greater than the number of correct programs for the problem. Students here are active, partnering in the elicitation and production of rejection rules. Alan does not simply enumerate lists of such rules based, perhaps, on past sessions with other students, to be memorized and indexed by the current students in the room. Rather, Alan responds with specific rules particularized to the responses these students are making at this moment with respect to the program at hand.
Rules of Rejection and Their Learn-Ability
Throughout this study, we have shown how the living praxis of writing programs collectively between students and teacher can reveal much more 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 Table 2.
Table 2. Number of students writing at the end of Alan's writing or speaking turns, out of 14 students observable in the view frame of the side-facing camera.
In noting this key feature of joint code writing, it can more easily be made salient to new teachers of programming, 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 ability for learning is in the visibility of the practice as it is being constituted by those present. It is easy for teachers and students alike to become fixated on the end product, the final code, making such code the sole focus of instruction, all the while losing sight of the accounts that experienced programmers can, but not necessarily will, provide for all of the wrong turns novices inevitably make as they struggle to develop a program for a given problem. In addition, to support learn-ability in this pedagogical praxis, these rules of rejection are likely to be at least as important to preserve in some persistent 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 technological 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 comments within the document.
It is easy to view code as a purely formal object and conceive of its production as a straightforward matter of applying generative rules and routines to produce correct code to specification. With such a perspective, we can study expert behavior in isolation to try to determine such rules and routines and then seek in novices those deviations and missteps that lead them to failure. Here, we have taken a different perspective, inquiring into the actual work students and teachers do together in a signature pedagogy of the programming practice.
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 learnable 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.
Acknowledgments
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.
References
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), 970–977.
4. Dijkstra, E.W. On the cruelty of really teaching computer science. Commun. ACM 32, 12 (Dec. 1989), 1398–1404.
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, MA, 1979.
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, Norwood, NJ, 1991.
18. Wittgenstein, L. Philosophical Investigations / Philosophische Untersuchungen. Blackwell, Oxford, U.K., 1997.
Footnotes
a. The numbers in parentheses indicate the length in seconds of a pause in speech. Words inside parentheses indicate transcriber difficulty hearing the speaker, with the parenthesized words being the transcriber's best guess at what was said. Statements inside square brackets are transcriber comments.
Copyright held by the authors. Publication rights licensed to ACM.
Request permission to publish from [email protected]
The Digital Library is published by the Association for Computing Machinery. Copyright © 2018 ACM, Inc.
No entries found