Finding Poetry in Technology
How Creative Writing Made Me a Better Engineer
The written word was my first love. From the moment I could, I devoured books — under the dinner table, in the dentist’s chair, during recess. While my friends’ parents would take away their cellphones or revoke their party privileges as punishment, mine would take my novels. I won silly reading awards at the community library, received silly writing awards at school, and studied creative writing in hopes of someday receiving less-silly literary accolades.
When I began teaching myself to code a few years after graduation and realized I could be interested in programming, it was a revelation. In my mind, programming was as far removed from writing as possible — one of the last things a bibliophile like me could, or should, want to pursue. Friends and family saw my transition as an innocent change of heart at best, “selling out” at worst. For months, I felt a pang of guilt for leaving my first love for this exciting new fling.
But since my leap into engineering, I’ve discovered that the parallels between writing good prose and good code run long and deep. My training as a writer has fundamentally informed my approach as a technologist throughout my career.
After all, in both literature and code, the practitioner (read novelist or developer) starts with a more-or-less set toolbox. There are a finite number of characters to punch out onto the screen; it’s rare you are ever telling a story or solving a problem that has never been tackled in some form before. But with that set toolbox, we create both bawdy romances and heady Nobel Prize winners, both Candy Crush and life-saving technologies. It is the infinite ways we apply that set toolbox that creates magic.
Both writing prose and writing code take on this herculean task of cobbling together various parts to create an infinitely more powerful whole. They demand a set of rules that is part objective, part subjective and wholly unique to each craftsperson. There is science to good writing, a loose formula for a great sentence — just as there is elegance in great code, and poetry in technology.
The Process
Gene Fowler, journalist and biographer, once summed up the writing process with the morbid declaration that “writing is easy: all you do is sit staring at a blank sheet of paper until drops of blood form on your forehead.” To eke out a sentence one word at a time in a fashion that not only makes sense and follows the rules, but also satisfies one’s own aesthetic credo, is frustratingly slow work.
A similar frustration plagues me as I code. The complexity of a problem can paralyze me from venturing a first step, or a handful of smaller issues can distract me from getting into the groove of solving the larger one. Even when working on straightforward problems, managing the delicate balance between meeting deadlines and writing robust, elegant code is a constant struggle.
Avoiding writer’s block and getting into “the flow” is spoken about in almost mythical terms by authors and developers alike. “Flow” — that state where hours pass as seconds, and work comes pouring out onto the page unbidden — is a fickle visitor. There is no frustration quite as profound as not having the right thing to say, nor the right way to say it.
In either discipline, I’ve discovered that working with a partner or getting feedback from a group helps me out of mental ruts and catches potential missteps early. Writing and coding are often seen as lonely endeavors (the novelist shut away in an attic, the developer hunched over a laptop in a basement), but both can, and should, be collaborative efforts. An author relies on teams of editors to give rounds of feedback; a developer works with countless other engineers to write, review, test, and maintain code. Writing with teammates ensures that my work won’t steadily meander off course or develop gaping holes.
The writer’s mantra to “rewrite, rewrite, rewrite” rings true for development as well. While readers claim a book is not truly enjoyed until it’s been reread, writers similarly claim a draft is not a first draft until it’s been rewritten once. It is only in the revisiting that ideas crystallize into the purest form of themselves. Loose ends are tied up; ideas are swapped around in line; whole stubborn paragraphs are axed and rewritten.
In programming, rewriting dons the more technical term of “refactoring”, but the concept is the same — developers revisit the solutions they messily implemented under the pressures of deadlines in an effort to pare them down to their most unadulterated forms. It may mean abstracting out common patterns, renaming functions in more semantic terms, or breaking monolithic modules down into smaller ones.
As writers and developers will tell you — no work ever reaches perfection. French poet Paul Valéry famously declared, “A poem is never finished; it is only abandoned.” So it also is with growing codebases, and the books that we slowly outgrow as we write them.
The Rules
While we may wax poetic about how we write for ourselves, the reality is that writing is an exercise done with an audience in mind — even if that audience is our future selves. With that comes the expectation that our writing isn’t a self-indulgent sort of show of how many esoteric words we know, or how many lines we can floridly go on for. It is produced for someone to gain something from its reading, practical or otherwise. It reinforces the sentiment that straightforward elegance always trumps vague fluffiness. It should be simple, but gracefully comprehensive. It may take fewer words, but will ironically evoke more meaning — the message becomes more accurate, more full.
Both good code and good writing are delineated by this clarity of purpose — by a clear understanding of the ultimate goal. It is painfully obvious when code has too narrow a view of its functionality, or an essay has no idea of where it is headed until it accidentally wanders there (if it gets there at all). The purposeful organization of ideas and the deliberate orchestration of moving parts mark the masterpieces.
Conversely, bad code and bad writing share root causes. The oft-repeated mantra of “show, don’t tell” that our high school English teachers drummed into us applies just as well to code. Instead of describing a character with a long slew of adjectives, writers are encouraged to describe that character’s actions and feelings — it accomplishes the same outcome with more dynamism.
In development, unnecessary exposition comes in the form of comments. If code must be peppered with explanatory comments in order to be intelligible to the next developer, it is probably not very well-written code. Naming variables semantically, grouping constants, and organizing files in intuitively named directories are just a few ways in which developers can use form and content to make their code speak for itself.
The Story
And yet, for all their similarities, there are the obvious fundamental differences. Code’s value rises with how “generic” it is — by being exceptionally “common” and stripping out anything esoteric, it can be understood by all developers. Nothing is gratuitous, and everything is as efficient, scalable, and reusable as it can be. The author’s ego disappears, because code belongs to no one. Once released to the open source community, it is forked, maintained, and extended ad nauseam.
Writing’s value, on the other hand, lies in how uniquely it addresses a universal sentiment or common experience. There have been tens of thousands of books written about World War II, and yet something about Kurt Vonnegut’s idiosyncratic, almost poetic, take on the disorienting effects of trauma strike a particular bittersweet chord with readers. Maximum scalability is not the main end. It is getting to the heart of an experience in a way that is unique, even if that experience is not.
My childhood (and ongoing) enchantment with books had a great deal to do with how they instantly opened up my world. I was stuck on a cloistered cul-de-sac in a sleepy suburb, but I time-traveled regularly to gallivant with knights and Vikings, shot into other dimensions to fly with witches and wizards. I’ve lived hundreds of lives, rejoiced in hundreds of victories, grieved hundreds of losses.
I’d argue that technology — at its best, at its most well-intentioned — accomplishes the same thing. It condenses the world down to something people can hold in their hands. It allows them to share more of their stories with an ever-growing audience — to communicate more fully and more often, to even feel their humanity more. With the advent of exciting mediums like augmented and virtual reality, we can even more fully experience what it is like to live out someone else’s story. Technology, at its best, is fancy storytelling.
Those who raised eyebrows at my transition from literature to technology believe that those are completely divergent disciplines, but I’d posit that they’re similar in countless ways. Good code tells a clear story; good stories have the purposeful architecture of a codebase. My drive to articulate my purpose before writing, to ruthlessly edit and re-edit my work, to kill my ego in service of the final product — these skills have driven my success as a developer, but first took root in my love of the written word.
Presence Press is a digital product strategy and development publication. Ideas expressed by writers are their own.
Today, every company is a software company. Presence helps companies make great digital products. We have the chops to help with strategy, design, engineering, and process for web, mobile, VR, AR, and Salesforce products.
