Back to the Future:
Communicating with Computers and Programmers in
Introductory Computer Science
Brian C. Ladd
Computers and Writing 2005

Computer programs are bipolar texts designed to communicate with both a
human and a machine audience. The focus in introductory computer science
courses is too often on the machine audience to the detriment of writing to
communicate to other programmers. The compartmentalization of "writing"
tasks in a designated software engineering course only exacerbates this
problem. Students who understand that computer programming is writing can
apply their collection of writing tools to produce better computer
programs.

Computer programming is writing; it is writing for two audiences, human and
machine, and it is writing with two different modes of presentation,
listing and execution, but it is all writing. Interpreting computer
programming as a new and foreign task, students are unable to bring to bear
the writing tools they already have. The result is less success and greater
frustration than is necessary.

Beginning programmers focus on the novel aspect of their new task,
communicating with the machine, to the exclusion of writing programs that
other programmers can read. Unfortunately for beginning programmers,
ignoring the human audience leads to shallower thinking about both problem
and solution and typically makes getting the execution "right" even harder
than it needs to be. Students need to remember both audiences for their
programs.

This paper reports on the use of traditional writing across the curriculum
(WAC) techniques (Young 1999) to help students remember both audiences when
they are writing their programs. Multiple drafts and guided rewrites
accompanied by self-reflective rewrite essays draw on students' experiences
in their writing-intensive First Year Program. Intentionally mimicking
writing assignments the students have seen before makes them aware of the
parallels between the two tasks. It also drives home the need for similar
attention to writing for a particular audience or audiences. This serves to
keep in mind the human audience too often forgotten in the heated rush to
overcome syntax errors and core dumps.

Another WAC technique adaptable to computer programming is the idea of a
"one-minute design". Students are presented with a specification, given a
chance to read it, and are then given one minute to sketch out their
solution to the problem. This one-minute solution, much like the one-minute
essay or free-write it is modeled on, is seldom a masterpiece. It does
serve to make the student engage the specification deeply enough that they
begin to know what they don't know; this prompts students to either ask
questions or, even better, begin doing research on their own. The parallels
to standard writing assignments makes this natural to the students.

Students who have done a one-minute design have a small enough investment
in their proposed solution that they are willing to abandon it, sometimes
trying another one-minute design that excludes their previous
solution. Designs spawned with one-minute designs are more likely to
include discussion of alternative solutions and are often more deeply
thought out than those that are started with more formal versions.

The computer programs written from these designs tend to communicate well
with the human audience without sacrificing the machine audience. In fact,
students who think about multiple approaches to a problem seem more capable
of dealing with the details required for getting the compiler to understand
their program. 

Software engineering is an occasional upper-level elective course in our
curriculum. While the course focuses on writing specifications, design
documents, and properly documenting code (using good variable names and
including appropriate levels of comments), the encapsulation of these ideas
in a single course convinces beginning students that they are "separate"
and "advanced" techniques rather than the core tasks of writing good
computer programs.

The complexity of most software engineering methodologies reinforces the
view that they are to be applied only in special cases. Good writing
techniques provide lighter-weight tools for developing good programming
skills.

Program evaluation changes in the face of treating programming as
writing. The grader must evaluate the program for both the human and
machine audiences. This introduces more work for the grader (it is no
longer enough to make sure the program compiles and gets the right answer
for the test input). The required philosophical change is in line with
current thinking in "real world" software engineering (Hunt 1999, Larman
2003, McConnell 2004) about extreme programming or agile development. The
programmer who takes ownership of the solution they write, describes it
concisely, and is willing to rewrite it as conditions dictates exhibits the
current best practices in the discipline. Discipline-centered writing
exercises develop these skills in beginning programmers.

Beginning programmers who approach writing a program as a writing task are
more likely to succeed than those who don't. The "writers" bring all of
their argumentative skills with them to the computer program. They know
that a human reading the program must be able to follow the program's
progression in order to believe it is correct; their writing for the human
audience facilitates their own writing to learn even while they are writing
to communicate. Writing across the curriculum tools can be fruitfully
adapted to introductory computer science courses to help students
understand that it is all writing.