Having spent most of my adult life working in the software industry, I see many parallels with writing and coding. What’s interesting is how these two subject domains differ in approaches to teaching—and what can we learn from both that can enhance how each subject is taught?
On an abstract level, both writing and coding involve encoding and decoding strings of symbols for intentional purpose, and both have highly evolved production processes with feedback loops. In addition, both have traditions and precedents that have spawned genres and styles.
On a deeper level, the metaphor holds up: First, both involve translating what’s in someone’s mind into actionable results—in the case of coding, to compile and execute a computer program that creates certain application behaviors and computational results, and in writing, to inform, persuade and entertain. Second, both deal with “languages,” “syntax” and “logic.” Inside these broad terms, the specifics are also similar; for example, word order, grammar, punctuation, internal and external references, and logic structures appear in both. Third: both require multistep production processes: although writing is usually thought of as an individual enterprise, to publish or post a finished product usually involves editorial and production processes. Coding is mostly a collaborative enterprise that involves multiple contributors and production processes (code management, compiling, testing and distribution).
Individual versus Collaboration
A few major differences between these two domains are noteworthy. Even though the image persists of a lone programmer knocking out cool programs (and this certainly still exists), most all professional programming is accomplished in the context of large systems and is therefore an inherently collaborative activity.
On the other hand, we still teach writing as an individual activity. When collaboration is involved in writing pedagogy, it usually means group editing and comment sessions—not creation. Because the teaching of writing has evolved from a literary-centric worldview, writers are responsible for finished products. An essay can refer to other people’s work, but the writer owns the essay, and the writer is responsible for its success. Interestingly, most professional writing is a collaborative activity.
Because coding is collaborative, programmers have invested much time in creating support systems to manage code, and most programmers are quite familiar with policies and procedures to create, compile and test code. In other words, coders work in a holistic production environment where they can manage and promulgate changes efficiently. Support tools for programmers are quite sophisticated—some tools provide organizational structure, language-sensitive support, and a variety of graphical interfaces to explore dependencies and flag issues.
Support tools for writing tools for writers, on the other hand, are not as sophisticated and tend to focus on document management. Interestingly, the document management tools today evolved from code management systems. True, many word-processing applications (Microsoft Word and Google Docs) have some primitive support for spelling and grammar, but none of these applications is as comprehensive and robust as what are available to the programming community.
Real-time Versus Batch
Another area that directly informs writing and coding pedagogy involves how each domain has evolved. In the old days of programming, when computer cycles were expensive, programmers developed code on punch cards, which were then compiled (translated into machine commands) and the results were displayed on printouts (often at scheduled times to accommodate demand). As compute speeds improved and computer cycles became inexpensive and as programmers gained access to smaller, more versatile computers with display screens, turnaround for processing code approached instantaneous—compiling became frictionless. What was once a batch process became virtually a real-time process. In addition, the compiling process expanded to include error checking. Programmers can now instantly determine whether their code is successful; and if not, what fixes might help. Team leaders oversee progress. The development environment that programmers use provides comprehensive coverage and support throughout the creation and production process. In addition, a separate testing cycle staffed by specifically trained coders exercise the program and report errors. Once the process and feedback loop wring out most of the problems, the program moves to another group that readies it for distribution. In this factory-like process, most of the applications that delight, frustrate or help us in our daily lives are born.
Most academic writing is still processed in “batch mode.” A student writes a draft essay and submits it to an instructor. The instructor reviews the draft, adds comments (sometimes edits) and returns the essay to the student for another go around. Often, students are on their own during the creation process using minimal computer support. Writing instructors might “process,” usually manually, 50 to 80 papers a week. With this workload, the coverage on a single essay often focuses on first-order problems such as structure, thesis statements and obvious sentence and word-order issues. If there is time for a second draft review, instructors highlight more errors. And so it goes until an instructor deems the product finished and gives it a grade. Most instructors have their own metrics for determining what works in an essay. My organization instituted a norming process that is quite helpful—given the varying differences in student ability and skills and instructor metrics. Although it may feel like a factory process at times, processing student writing is a relatively loose affair that manages to grind out some wonderfully inspiring work.
In Part 2, I’ll explore some ways writing instructors can exploit the coding model that empowers students to gain control of the writing process, produce better products and make life easier for all.