Surpassing Limits
Composition as coding may spur some to argue that students will not be writing enough; that code will dictate the content and form. Given the tools and resources freely available, their claims should be treated as dubious at best. But what of the other goals of composition? Shuchi Grover, (2013) in a response to Mitchel Resnick's article "Learn to Code, Code to Learn,"interrogates students critical engagement in ideas, a foundation of composition coursework:
Introductory exposure to coding in these environments is easy, hugely gratifying, and motivating. But how deeply do these children engage in computational thinking? The answer is, it depends… computational thinking involves conceptualizing, not just coding and learning the syntax of a language, and it's more about the ideas, not the artifacts. It is the thinking we employ to design solutions, not the end product or projects.
Teaching computational thinking, in some respects, reflects critical analysis and critique. In fact, Grover's challenge to code mirrors the process movement in composition: "it's about the ideas, not the artifacts." The emphasis here is on development and engagement, not necessarily product. It is not the solution, but the designing of a solution. When my technical writing students craft their final external reports, they are required to submit an electronic copy of that report. Such large documents are not exactly web-friendly; in fact, most company reports are found only in pdf form, as opposed to a report that can be navigated via hyperlinks. When I inform my students that they are required to turn in this electronic version (in addition to a bound hard copy), they begin to rework the format of the document, focusing on headers and navigation-based elements. Many include an HTML version of their final report. Their final products, however, are not as important as the methodologies they have used to arrive at those final products.
In essence, this is a new paradigm for computer science, one that rhetoricians and composition may greatly benefit from. Rather than learning every keystroke necessary to program a computer to say "hello world" or to employ CSS so that every blockquote has a uniform indentation, users must understand the reasoning behind each keystroke. So how do we go about this? Grover continues by conceptually crafting a pedagogical plan:
If the goal is to develop robust thinking skills while kids are being creative, collaborative, participatory and all that other good stuff, the focus of the learning needs to go beyond the tool, the syntax of a programming language and even the work products to the deeper thinking skills. While the fun features afforded by these programming environments make for great engagement, they often draw focus to the artifacts, many of which employ relatively thin use of computational thinking.
In other words, more than all the tools, more than all the resources, and more than simply creating small corners of the web or movies or apps or essays, learning and growth are always at the core of what we should be doing. The limitations of code are less about the technical matters involved in code creation and more concerned with what students learn from code—not if they learn to code.