Coding is like writing
Courtesy @aaronburden on Unsplash
I recently published a novel, and it got us thinking about the unexpected similarities between creative writing and software development. But (I hear you say), writing is Right Brain and coding is Left Brain! Leaving aside this increasingly questionable distinction, it turns out the two activities have a lot in common. Below I’ll touch on just three–scoping, communication, and improvement.
Chekhov’s Function
Anton Chekhov–one of the greatest writers of all time–famously said,
“If you say in the first chapter that there is a rifle hanging on the wall, in the second or third chapter it absolutely must go off. If it’s not going to be fired, it shouldn’t be hanging there.”
Chekhov’s Gun highlights one property of good stories: economy. Stories draw a circle around some part of life (however fantastical). They choose to include some things–people, places, events–and exclude others based on one criterion: does this help the story? Stories that don’t scope are littered with loose ends and plot holes, tax the reader’s memory, and lack that satisfying sense of motion and completion.
Good code has the analogous concept of YAGNI–You Aren’t Gonna Need It. YAGNI argues for coding fit to purpose now. It should be just complex enough to solve the problem and no more. Don’t add a function ‘just in case’. And in the same way that extraneous detail and fuzzy boundaries can derail a story, code that is for a future, imagined need, confuses developers, and hampers refactoring efforts (but I’ll come to that). As Elon Musk says, “The best part is no part.”
By humans, for humans (and computers)
Most writers assume a human audience; sadly, many coders do not. But they should. Sure, computers invoke your code, but it’s people who have to read it. They’re the ones with whom you’re trying to communicate.
In creative writing, this translates to knowing the meaning of words, and valid ways to string them into sentences (grammar). It makes educated guesses about the reader’s tastes, knowledge, and experiences. It tries to find common ground–genre is a word with roots in ‘family’. And when you get it wrong, violate the reader’s expectations, or invite misinterpretation, the results can be painful. It took me a while to learn that when faced with the choice between a fancy word and a simple word that does the same job, I should pick the simple word.
Similarly, there are many ways to communicate the meaning and intent of code. Thoughtful naming of functions and variables, factoring out duplicated logic, and comments all have a role. When I’m tempted to use the ‘fancy word’ of a terse code construction, I try to remember that doing so will shrink the audience for that code, and a simpler construction is better.
while (*dest++ = *src++);
The above code is clever. But understanding it requires knowing three non-obvious things about the C language. Better to take another line or two to avoid bamboozling your colleagues.
A bookCode is never finished, merely abandoned
This analogy might seem stretchy, but writing is rewriting. Rarely is the first way I express an idea the best way to express the idea. Surprisingly, the act of writing is often the means of figuring out what it is I want to say. Multiple rounds of editing–sifting, refining, choosing–are required to clarify my thoughts.
Below is a draft of the introduction to Simple & Direct by Jacques Barzun (one of my favourite books on writing). More edits were required for multiple subsequent drafts and the proof. It’s a demonstration of the iterative process of arriving at what you intended to say.
Likewise, very rarely is the first code I write to solve a problem the best code to solve the problem. Real world software also needs this iterative refinement to better understand and encode the true contours of the problem I’m solving. The result is simpler, faster, better, easier to extend. In software development, we call this refactoring. And it’s vital, particularly given the tendency in software for the problem to change.
These are just a few similarities between the crafts of creative writing and software development. There are many more, which shouldn’t be surprising given that engineering is an art, and science is fuelled by creativity. The connecting piece is humans. And Adapptor likes humans, but I’ll leave that for another post 😊