1. Introduction

Writing and programming might seem worlds apart: Writing is a creative activity, with goals ranging from entertaining to persuading, from structuring the writer’s thoughts to passing a message to the reader. Programming, on the other hand, is a form of problem solving, in which the programmer starts with a problem, creates a design - a plan of how to solve problem - and then solves this by writing code that a machine can execute. But when one takes a look below the surface, there are also clear similarities to discover. Most strikingly, both writing and programming can be described as the translation of a high-level idea into low level sentences or statements.

In this paper we explore the activities commonly performed in writing and programming with each other highlighting similarities and differences. For example, in programming, formatting and style receive less focus while explicit attention to these has the potential to make code more readable. In programming, code is executed and tested early in the process, while text is often proofread when more finished.

We believe that both fields can learn from a detailed comparison of activities. What does formatting mean in the context of code? Is it important? Can text writing be as iterative and test-driven as code? These are just a few of the questions raised by our side-by-side exploration. Does writing make you a better programmer? What skills underpin both? Can programming learn from writing education?

2. What is writing and what is programming?

So, what is writing? Writing is a way in which humans communicate, using letters and symbols, forming words and sentences. It is used for various different reasons and purposes, including but not limited to storytelling, correspondence and reports of various kinds. The term ‘writing’ is broad, and can be used for activities varying from the motor skill of forming letters to formulating thoughts, feelings and opinions, and to be flawless in the spelling of words and use of grammar rules (Paus, 2014). In this paper we focus on the activity of text composing, regardless the type or genre of the text.

And what is programming? Programming is commonly seen as the process by which a human formulates a problem in such a way that a computer can execute it. It involves understanding the problem, creating a design, writing the syntax of a program - sometimes referred to as coding - and performing maintenance on an existing program (Weinberg, 1985).

3. A high level plan executed in detail

One of the most striking similarities between writing and programming is the fact that in both, there are high-level plans. A murder mystery writer imagines a killer that stabs blond men with stiletto heels; while a programmer imagines an iPad app to manage different bank accounts. These high-level plans are sometimes, but not always, formalized to a certain extent. Writers create designs before they start. A programmer might draw a UML diagram or an architecture plan, and writer creates a table of contents before writing, or uses character sheets and scene descriptions.

Afterwards, these high-level designs need to be translated into very low level constructs: sentences and words for the writers, and methods and lines of code for the programmers. How to approach this is a topic for many methodologies in both writing and programming. Is it better to draft broadly and then iterate, or to take one chapter or feature and make it perfect before adding others? There are people on both sides of the argument in both writing and programming. In writing these two extremes even have terms: Pantsers and plotters.

To help manage the complexity of the translation, in both fields, there are intermediate steps. A writer divides a story into chapters or an essay into sections. These in turn are divided into paragraphs and sentences. Likewise a programmer thinks of classes or objects to contain some parts of a program, which have methods and fields in them.

One aspect where the high-level idea into low-level implementation transformation can lead to problems is when changes need to be made. No text is perfect at the first try; books and stories are often reviewed and rewritten, sometimes assisted by formal reviews. Programmers review each other’s code and suggest changes, or fix bugs in existing code bases. In this adaptation, the high level translating again plays a big role. If writers decide to remove a character from a story, they need to make sure it is deleted from all chapters. If programmers change their architecture, this will result in changes to many classes and methods.

4. A deep dive into activities

So far, we observed the crux of the similarities between writing and programming: the translation of high level ideas into a lower level, the realm of words and letters. We now examine the steps of which the activities of writing and programming consist in more detail, drawing comparisons and highlight differences. The comparison of steps will help us gain insights into both processes better. Where are the procedures similar? Where can we learn from each other? Do we understand striking differences?

There are a number of models of the writing process available, e.g. (Huizenga, 2004), (Paus 2014), (Flower & Hayes, 1981), (Rohman, 1965), all similar in the general picture they paint. The writing process can roughly be divided in three phases: pre-writing, writing, post-writing, which in turn can be divided in two or more sub-phases. Similarly, the process of writing a computer program generally is divided in three phases, resembling the phases in the writing process: design, implement, test, or problem solving, implementing, maintaining (Dale, 1992).

There are more fine grained models too, which we will use here to explore the commonalities between writing and programming as extensive as possible.

In this paper, we use two more fine grained models, for writing we use (Huizenga, 2004) and for programming (Prata, 2013), both consisting of seven steps, as shown in Table 1 (while there are other steps that could be distinguished, we compare these two as an exploration of the activities. We do encourage readers to find other sources, or even define their own steps on one of the two activities and compare those).

Looking at these steps, we immediately observe similarities, which are graphically depicted in Figure 1: Gathering information corresponds to Defining Program Objectives, since both relate to analyzing the environment of the text or program. The following steps are similar too. Selecting information and Structuring information are related to Designing the program, since in both decisions are made about the underlying, often invisible structure of text and program.

In programming on the other hand, there is Compiling and Running the program. This represents a difference between writing and programming, in programming, the programmer gets feedback very early on whether the program text is executable, during compiling. Furthermore, they get feedback on whether the program is working as intended. One could argue that, in writing, the first ‘execution’ of the program happens when someone else reads it, and that it is thus takes longer to know whether a text has the desired intend. Of course writers themselves can read the text and ‘execute’ it, but the question is if that really executes the text alone. If the writer reads the text, can they refrain from also taking into account the context and intentions?

In the remaining sections, we will first discuss the similarities in the first and last steps, and then the differences mainly occurring in the middle parts.

5. Similarities

In this section, we zoom in on the similarities in the steps, which mainly occur in the beginning and end of the process.

5.1 Getting to know the context

The first steps in both fields concern the context of the text and code. What needs to go in? Who is the target audience? What do I want my text to convey, or my program to do?

When starting a new project, assignment, or exercise in writing or programming, the first step is setting of the goals. What subject must the text be about, or what problem must the computer program solve? What kind of text does the writer wants, or has, to write; a fictional story, recipe, or maybe a blog on his website? Who is the intended audience and what are the demands of a possible client or reader? With these goals in mind, writers start gathering information about the subject. They may use various kinds of sources like their own imagination and emotions, experiences of others, information found in external sources like books, videos and websites about the subject.

In programming, the gathering of information is a field of research in itself: requirements engineering. There are numerous different techniques for eliciting the requirements from a user (Kotonya, 1998), (Sommerville, 1997), (Pohl, 2010).

In this context, we are mainly talking about the process in which software is made for a customer. Of course, there are also projects that start because programmers really want to make something for themselves, without fixed requirements. Even in that case, a first step will often be gathering information, such as which programming language, library or API to use, or what similar system might exist.

5.2 Making plans

After the exploration of the context, there is a focus on designing the artifact. What will the storyline be? What is the structure of the argumentation? What characters are going to appear in what chapters? These contemplations could be comparable to questions like: What will the architecture of our system be? What classes and methods will we have? or What programming paradigm fits our problem best?

From all the gathered information the writer selects the useful information for this specific task, after or even during the information gathering process. Writers choose which information is relevant for the reader to understand the story line and also fits the chosen subject of the text.

The selection of relevant information too is a skill important in programming, again, especially in the commercial setting of creating software for an internal or external costumer. Different features of the program to be created are classified by importance, for example using the MoSCoW model (Clegg, 1994), or user stories are created, which are then grouped into sprints. By categorizing important features, programmers are deciding what information is most important for the program.

In writing, the gathering of information can be more vague, especially for writers of fiction, maybe the gathering is more of inspiration than of information. After gathering information and selecting the relevant parts, the writer organizes all information in a way that suits his habits in writing and fits the requirements of the text identified by the goals.

Ideas can be collected and structured in various multi- or one-dimensional ways. For example using a mindmap which represents relations between concepts, arguments and/or characters. In case of a recipe or manual writers may use a flowchart to structure their ideas. They may also provide short descriptions for characters, situations or scenery. Once gathered and organized ideas, the writer has an abstract representation of the text in mind.

Structuring in programming means creating a high-level design for a program. In this phase, design decisions are made about the program, such as, for example: what programming language and database system will be used? What type of software architecture will we follow, for example a model-view-controller or a micro-services setup. Lower level decisions are also made, such as what classes are needed and how they will related to each other. That is often done using a class diagram or an entity relationship diagram when data is being structured.

5.3 Translating

In writing, the step following Structuring information is Translating: transferring abstract concepts to linear natural language. While putting the design into sentences and words, the writer has to abide by rules. These rules might be rules of the language, for example, words need to be spelled correctly and sentences must be correct grammatically, but may also depend on the context of the text, for example in a scientific article, references have to be correct and in an persuasive argument, the text structure should be logical.

Similarly, the programmer now moves from the whiteboard to the keyboard, to start produces lines of code which implement the high-level design. Like in writing, the programmer needs to do so while applying rules. For example, code must be syntactically correct in order to be compiled or interpreted. In addition, some languages have stricter rules about what is allow, like typing rules that the programmer must obey.

According to (Flower & Hayes, 1981), in this process, the writer has to juggle different specific demands of written language varying from generic and formal, syntactic and lexical to the motor tasks of forming letters or typing on a keyboard. For example, when a writer has difficulties with the spelling of the words, this process will use up so much of their working memory that they have no room to think about the structure of a paragraph. This high ‘cognitive load’ has been studied in the context of programming, and programming education, as well (Harms, 2013), (Sweller, 2016), (Shaffer et al., 2003)}

5.4 Reflecting and Reviewing

We will reflect on differences in the remaining steps in the next section, but for now, let’s move to the final step of writing and the sixth of programming: Reflecting on text and Testing and Debugging and Maintaining and modifying the program.

After the text is written - and often also during the writing process - the writer reflects on their process and product. Are the goals met? Have I lived up the expectations of the assignment or client? Is my text readable?

Likewise a programmer reflects: Does my program function as expected? Is this code well-structured and free of code smells? Here, of course, there is an interesting difference between writing and programming, since a programmer can party rely on the computer to validate their program. Firstly of course by the compiler and the type-checker in statically typed languages, and later by an interpreter and a runtime. Furthermore, programmers increasingly often use tests to ensure the correctness of their programs. To find bugs, but also to ensure code quality, programmers sometimes use static analysis tools (Johnson et al., 2013).

Failure to compile, to pass all tests, or too many code smells might impose a need for a revision of the source code. This type of product-inherent warnings for review is not present in writing texts. While this is a clear benefit, this might also reduce the need for or interest in manually reviewing the source code, not for functionality, but for readability. Recent systems for collaborative programming, like GitHub and their support for code review via pull requests have spurred interest in code reviews for readability and maintainability.

These steps seem very similar, as they concern verifying that the text or program performs the task it needs to. However, programming has a seventh step, in which the program is maintained. Often, of course, programs are updated after they have been deployed, while books or articles typically remain the same.

6. Differences

In this section we highlight differences between the models of Huizenga and Prata. As said, there exist other, different models, which would lead to different comparisons. These two list are our choice, but we encourage others to make more, and different comparisons.

In our lists, we observe that not all steps are as similar as the first and last few steps. In the middle, we observe more differences than similarities, which we will elaborate on in this section. The most important difference is that in programming, making the source code is just one step: Writing the program, while in writing, there are two additional steps related to the stylizing and formatting of the text. In this section we will elaborate on what these steps mean in writing and how they could be interpreted in programming.

6.1 Stylizing text

When the ideas of the writer have been translated into text, a writer will apply rules of style. For example, an essay has a formal style with longer sentences and advanced jargon, while a children’s book is written in a cheerful style using simpler words. It is generally agreed upon that in order to write a good document, the writer has to apply a style to an entire document consistently, otherwise the text might be harder to understand, or less enjoyable to read.

Style can also depend on the intended audience of a text. When writing a letter, for example, the choice of style is related to the intended addressee. The style of a letter directed towards a loved one differs in various ways from the style of an job application letter.

In addition to these type of styles, prescribed by the goal of the text, many writers have their own personal style. This personal style might consist of the heavy use of adjectives to describe scenery, or the strict avoidance of multiple clauses. Other examples are the use of different perspectives, such as first or third person, or the omniscience of a narrator. Such a personal style will automatically be applied by the writer throughout the entire text, and therefor differs from the above described styles imposed on the writer.

As the French writer Raymond Queneau shows in (Queneau, 1981), many styles can be used to communicate the same content. By using different styles, the atmosphere of the text can strongly vary. Writers often experiment with styles to find out which one fits the intended feeling best.

Figure 2 and Figure 3 show two exercises from Queneau (source of translation); Surprise and Hesitation. Readers can check for themselves that on every singly line, in every single sentence, the writer has stuck to the chosen style. This reflects in specific words (e.g. ‘how’ in Surprise and ‘but’, ‘don’t really’ in Hesitation), types of sentences (short and firm in Surprise and long and intermittent in Hesitation) and punctuation (exclamation marks in Surprise and dots and question marks in Hesitation).

Figure 6 shows two versions of a diamond poem: in the first draft the text is formatted using practical constraints, the writer has only outlined the poem by its requirements (number of characteristics of the animal per line), the final version of the text has a different shape (diamond), different font, different background color and there are images added.

Despite the existence of these required, advised or automated formatting measures, programmers do still have some freedom in the formatting of their source code. As an example, consider the two code snippets in Figure 7.

Both programs are following code conventions, however, they feel different. The distance between the declaration and the use of a variable might influence the understandability of a piece of source code, or simply the enjoyment with which someone would read it, underlining the importance that formatting can have on a program, even within the limited freedom that a programming language offers, compared to natural language.

int a;                int b;
int b;                int x;
                      int y;
int x;                
int y;                int b = x + y;
int z;                
                      int a;
int b = x + y;        int z;
int a = b + z;        
                      int a = b + z;