Do you know that joke about two little fishes that swim into an older fish? He asks the young fishes how the water is, and they respond: “what’s water?”. The little fishes live and breath water, so they have no clue that it is even a thing. I love this joke and I often try to be aware of the waters of programming. What are the things we believe so strongly that we can no longer realize them?

What is programming? What is the essence of programming? Ask 10 people this, and you will get 10 answers. But despite the differences there are some things that are generally accepted in programming. For example, programming is technical, we are software “engineers”. This belief leads to other assumptions, for example that you need math skills to be a good programmer.

But is this a fact or a belief? What if programming had more resemblance to another important skill: writing? What would be different?

How programming is really writing
Together with Marlies Aldewereld, a teacher and researcher at Pabo Windesheim (a school for teachers), I recently wrote a paper called Programming is writing is programming in which we outline why programming and writing are in fact two sides of the one coin. The core idea of the paper is that programming and writing are both, in essence, the activity of taking a very high-level idea and translating it to low level statements: 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? In both fields, there are people on both sides of the argument. In writing, these two extremes even have terms: pantsers and plotters.

One aspect where the high-level idea into low-level implementation transformation manifests is when one makes changes. 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 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 changes their architecture, this will result in changes to many classes and methods.

Am I a keyboard?
Of course, observing similarities between fields can be interesting in and of itself, but the question arises, of course, what we can learn from this. Given enough layers of abstraction, all things are similar. I am an object, the computer on which I type this is one too, but what insight does that give me?

Well, the way we view programming impacts the field. We take our words and concepts now from, for example, engineering: building, systems, maintenance, scaffolding. But the field of writing has to offer us a lot too. I for one have found the plotters and pantsers views very appealing also for programming, some people like planning, while others want to see where the code takes them. The same person might even be plotting sometimes and pantsing in other situations. The metaphor of software creation as ‘software engineering’ feels as designed by and for plotters.

Here’s a thought: If we had viewed programming more alike writing from the start, would we have come to agile design methodologies sooner?

Impact on education
It is not just the way we think about programming, but also the way we teach it that is greatly influenced by the way we see our field. If we see programming as writing, can we learn from writing education? This question warrants a full paper, but there are a few directions we see we can learn from. Could we apply these methods to programming education too?

For example, in writing observational learning is the most prevailing way of using models for learning. In this teaching method the teacher thinks out loud, they explain and demonstrates parts of the writing task. Especially the model where teachers make mistakes and backtrack raises the self-efficacy of the pupils and enhances their performance more effectively.

What if we taught programming like this, by programming while thinking aloud? Would that be effective?

A second inspiration comes from topic integration. Writing can be taught in isolation, but can also be taught in combination with other topics, for example, when pupils are writing an essay about modern history. A study compared the effectiveness of two different methods of teaching science: one aimed at just teaching science, a second on combined with reading and literacy. In this latter group the kids learned to think, speak, read and write like scientists. The other group got more traditional science lessons. This second group had a better understanding of what science is, a better understanding of the basic concepts and also they identified more as scientists.

This last study could prove especially interesting for programming education, as it also could help a broader group of kids identify as programmers! But oops, I think I am talking about inclusiveness again…. time to go to bed.

PS A huge thanks to some people that have took time to think with me over the last months: Sam Aaron, Kevlin Henney, Alan Blackwell, Tomas Petricek, Llewelyn Falco, Luke Church and many others!