Writing Code is the Same Thing as Writing Prose
The act of writing Code and writing Prose is the same. They both use the same mental processes, have language constructs and audiences, and require significant focus to be effective. I’ve written code and countless technical docs and articles for well over two decades, and lately started writing fiction. This article has been percolating in my head for years. Let’s dig into how they are the same.
Language
Both Code and Prose are written in a language. My prose is in English, and while I’ve written code in C, Java and Perl, I’m most familiar with Python.
Counting the number of words in English is not simple, as this article by Merriam-Webster explains, but there are roughly 470,000 English words. A typical English speaker knows between 20,000 and 35,000 words, depending on their level of education.
Python, like most programming languages, has a very small set of keywords and constructs, and the real value is in the shared libraries, or pips in the Python world. PyPi, the repository of those libraries, has 498,650 projects, or pips, listed as of December 5, 2023. A recent small project I was working on pulled in 68 of those.
It’s a bit nonsensical to compare the number of words in English to the number of packages in PyPi, but we can agree that both English and Python are very rich languages, and no single person can reasonably understand the full scope of either language.
Compilers
The concept of a compiler is fairly simple: translate human-readable code into machine-readable instructions. In this example below, the python code is supposed to print “Hello World!” ten times, with the assembly code generated on the right. I can’t read assembly code, it’s a completely foreign language to me, but that’s not important because the computer can read and execute it.
When writing prose, the reader’s brain becomes a compiler, translating the words from screen or paper into tangible thoughts and images, even if the words are not strictly correct. A great author can describe a scene so vividly that you can see it in your head even though the words are just pixels or ink.
My favorite line of prose is by Stephen Leacock in Gertrude the Governess “He flung himself from the room, flung himself upon his horse and rode madly off in all directions.” This is where admittedly my argument falls apart, since the last part of that line does not strictly make sense, yet our brains can see past it and conjure up with a vivid image that’s captured the imagination of many readers. A compiler would throw an error like:
HorseError: Horse can only gallop in one direction
ChatGPT also struggles to make sense of it, this is the best it could do.
Audience
Every writer has an audience, even if they aren’t aware of it or think explicitly about it.
A writer of prose might be writing a journal that will never be seen by anyone, and the audience is themselves. Or they may be writing a draft of a book that will hopefully catch a publisher’s eyes. Or, like so much of my writing in my professional life, the audience for technical docs is made up of my peers who need to understand the reasons why something is built the way it is.
Software Developers have two audiences. The first is the compiler and runtime, after all a piece of software that won’t compile or run, or worse do the wrong thing when running, is useless. But the far more important audience is the next developer who has to read or edit the code. It’s very easy to write unreadable code, it’s far more difficult to write code that another developer can easily understand. And beware, that next developer might be you. Countless times I’ve thought, who wrote this crap and a `git blame` (a whodunnit in software development) showed that I was the author a few years ago. Oof. If you want to see some terrible and beautiful examples of functional but completely unreadable code check out the Obfuscated C Code Contest. Once you’ve written code, someone has to maintain it, and that future developer is your audience.
Generative AI as an Aide
I recently started writing fiction, which is the quality of Vogon poetry and should never see the light of day, but that aside I found that ChatGPT made an excellent research assistant. My story took place in Ireland around the Great Famine in the 1840’s, and much as I want to research my story by exploring Ireland for a few months, a more reasonable approach was to ask ChatGPT questions like:
- what are some Irish first names in 1840’s
- how much salary did a farm laborer earn
- how much did a train ticket cost
- what’s the name of a ship that went from dublin to quebec in 1847
It happily gave me answers. They may have been wrong answers, but ChatGPT responded fast enough for me to be able to continue writing without interruption or expensive overseas trips, knowing full well that if the Vogons ever decide to publish the writing they would have to do some serious fact checking.
On the code side I subscribed to GitHub Copilot, and it is very, very good. It definitely hallucinates at times, and occasionally is completely wrong. Where it shines is that it understands the context of what you are working on. In a real “duh” moment I forgot how to do multi-line strings in Python, and asked it “how do make the string in line 43 multiline so it’s not more than 120 chars long” and it rewrote the line for me. I also asked it for an AWS CloudFormation template with some specific features, partially as a test and partially because I was lazy, and while there were a few errors, 95% of the template was correct. GitHub Copilot is like having a very senior developer sitting beside you, always available for questions.
Generative AI has far too much hype today, and it can be wildly wrong, but it’s an extra tool in the writer’s toolbox that’s worth spending some time to learn.
Environment and Tools
The best writing and coding happens when the author can get into the flow, or into the zone, into the Deep Work space that Cal Newport writes about in his excellent book. Deep Work requires a quiet space without interruptions, and it takes practice to get into that mode. Unfortunately most software shops do not recognize this, distractions abound in the form of Slack/Teams/Email notifications and meetings, and software quality suffers as a result.
Tools for authors and developers are abundant and varied. For authors this may be pen and paper, Microsoft Word, or Google Docs or something else entirely. I’m using Google Docs for this article, because for the most part it Just Works™ and stays out of my way. For software developers it’s typically an IDE like IntelliJ or VSCode. I strongly believe that a specific tool should not be forced on writers, because that will wreck the writer’s flow. If you’re a leader employing writers of prose or code, those writers are your most expensive asset, and spending a few extra dollars on the tool of their choice will make them far more productive.
Writing is an Art
Writing prose is definitely an art, even potentially dry technical documentation can be artfully written. Many developers, including yours truly, will argue that writing code is also an art. There is a lot of very bad art, so much so that The Museum of Bad Art exists, and it’s well worth a visit. The art of writing has also produced some spectacularly bad prose. If writing code is an art, the same can be said that there is some horrendously bad code out in the wild. The code submitted to the Obfuscated C Code Contest is purposely horrible, but most software developers have run across code so bad that it’s better to throw it out and rewrite it rather than try to understand the mess and fix it. I’m sure some of my code falls into that category as well. But occasionally you stumble across a piece of code that is a work of art, it’s easy to read and understand, it’s efficient and well-documented, and masterful in all ways. When you see that and need to make a change to it, you’re like an artist restoring a famous painting, trying desperately not to make it worse.
Failure
One of the tips in the 25 Tips for New Developers is “Get comfortable with failure”. That applies to both code and prose. Writing code is hard, understanding the execution runtime can have a huge learning curve. Writing prose, especially fiction, can also be extremely hard. As I’ve proven to myself with my Vogon-esque story, inventing dialogue and creating characters from nothing can be extremely challenging, and failure is inevitable. I’ve ripped out entire sections of code and entire chapters of prose, starting over in both cases with knowledge learned in the failing, making me a better writer in the end.
Learning from each other
Medium has a lot of information on how to become a better writer. If writing code and prose is the same, then a lot of the advice targeting writers should also apply to software developers. This article on Stephen King’s writing routine could easily be applied to writing software. Admittedly it’s more difficult to create his environment in a paid software developer position, but it is possible. In the early stages of Arctic Wolf we talked extensively about how to create a good distraction-free environment, with large blocks of time that were meeting-free, and even entire meeting-free days. I had some of my most productive writing times in that era.
If you read the 25 Tips for New Developers article and substitute writing prose with code, much of the advice applies to new writers. Things like “Find a Community”, “Find a Niche”, “Focus on the fundamentals first”, and “Build projects you love” all can be applied to writing of all kinds.
Now go and write!
Werner Vogels, CTO of AWS, always ends his keynote speeches with “Now go and build!” It doesn’t matter if you’re writing code or prose… Now go and write!
