Code As Communication
Craft and Process
I know some very great writers, writers you love who write beautifully and have made a great deal of money, and not one of them sits down routinely feeling wildly enthusiastic and confident. Not one of them writes elegant first drafts. All right, one of them does, but we do not like her very much.
— Ann Lamott, Bird by Bird
In popular media, software engineers (there are like three software engineers in popular media, the rest are “hackers,” but you get it) and writers, the prodigious ones at least, are frequently portrayed hunched over their keyboards, fingers flying furiously across the keys. They struggle only to keep up with the high-pressure stream of immaculate ideas being channeled fully-formed into existence through their deft and steady hands.
This is, as Ann Lamott called it, “the fantasy of the uninitiated.” Really, writing and coding have felt very much the same to me. They both involve a lot of blankly staring at the screen, reading over what I’ve already written, realizing it’s all wrong, and trying to make it work anyway before finally gaining the courage to start over.
Writing and coding are ultimately both crafts. As crafts, they both reward process and attention to detail. In reality, where the conceptual rubber hits the productive road, when our purpose is to create something people will use, we have to develop a formalized practice, much of which will not involve channeling the divine. Rather, it will probably involve careful planning, iteration, and reflection.
In writing, there’s an old, Beat Generation salve attributed to Allen Ginsberg about “first thought, best thought.” This is, luckily and for good reason, not a practice taught often in college classrooms. Turns out, while it may yield some hip jazz poetry, “first thought, best thought” doesn’t often yield highly effective communication. Likewise, it’s unlikely that our first attempt at a component or algorithmic solution to a problem will be the most precise or functional we can come up with. In fact, there’s a term for first thoughts in coding problems: naive solutions. And it should be telling that there is no pejorative connotation to “naive” here.
There is a place for first thoughts. In writing classrooms, we still harness the power of uninhibited thinking in exercises like “freewrites.” However, freewriting is just one tool in a toolbox labeled “prewriting.” It’s a good first step rather than a destination — a thing undertaken before the real work begins. Prewriting also includes more structured, procedural exercises like mind-mapping, outlining, and researching.
In code, we have a similar “prewriting” phase. Instead of freewrites, we have pseudocode. Instead of mind-mapping we have diagramming. Instead of outlines, we have wireframes. And in place of research, we have SO. MUCH. research. The resulting practice is the same. Whole big swaths of the creative process happen before anything resembling a final product is committed to page or screen.
Developing a Practice
When the planning is done and we have a roadmap for progress sprawled out in front of us, we will feel no more or less inspired. As Ann Lamott points out, it’s rare that we work in fits of inspiration. If we wait for inspiration to strike, we may wait a long time. Even when it does strike, even if we wring ourselves out every time we catch a manic wave of enthusiasm — forgoing hygiene, missing meals, living on sleep deficits — likely enough, we’ll still be less prolific than the person who puts in his or her time every day.
Think about New Year’s resolutions. We all feel inspired after a month of feasting and rampant consumerism to get a gym membership and download a budgeting app, but this burst of shame-driven motivation rarely translates into an actual practice. I run when the weather is nice and never otherwise. My dad runs even when it’s 15 degrees out. Neither of us wonders why my mile pace hasn’t surpassed his.
Getting better at something requires exerting willpower to do it consistently, even when it isn’t fun. Writers know this. Developers know this. Writers can make good developers because we are used to the ebbs and flows of inspiration as much as the daily practice that gets things done.