Programming is Writing

January 6, 2024

At my workplace, there are articles published regularly on an internal news board sharing what's going on around the company. Most of it is laudatory presentation of company milestones, advice of varying quality, or interviews with influential employees. Sometimes there's the occasional letter from senior leadership about some new policy. Usually, I only click through them when I'm procrastinating something.

Recently, I landed on an article by one of the company's top technical writers, Mark Sillup, regarding writer's block. Most of it was advice that you could find elsewhere online; the points about setting a consistent schedule, taking breaks, and occasionally just doing what it takes to get something on paper, are also found in Stacy Lu's article with the APA on writer's block. But there's one point that did stand out, and at the risk of breaking company confidentiality, I'll share it: "Be a technician, not an artist." Sillup spends a few sections of this article explaining that trying too hard to be eloquent can lead you to get in the way of yourself. Instead he advocates a more utilitarian "just get it down" approach, but what stuck out to me was the line's assertion that technical writing wasn't art.

For a long while, influenced by Paul Lockhart's A Mathematician's Lament, I've considered both math and programming to be forms of art. I regularly see people who tend to treat them as heartless sciences reserved for geniuses, but Lockhart spends much of his essay showing that math is indeed an art. When he finishes comparing modern math education to an alternative dystopian version of art education, he invokes mathematical giant G.H. Hardy to explain that "a mathematician, like a painter or poet, is a maker of patterns. If his patterns are more permanent than theirs, it is because they are made with ideas." There are also people describing programming in similar ways: Robert Martin's Clean Code cites multiple well-known programmers with similar sentiments, and the book's subtitle is even A Handbook of Agile Software Craftsmanship.

I've fought for years across online circles to try and explain that math is a creative process, and fight the image that traditional primary education tends to build of it. With this experience, it surprised me to see an established writer, surely on the side that most of society would consider more creative, saying that writing is a technical craft. "Be a welder, not a sculptor," Sillup writes, further clarifying that in business writing the goal is not to make something fun, but to build a simple frame that supports one's ideas as efficiently as possible. As an artist, it stuck out to me. This isn't unique to business writing, either. If we return to Lu's article, I'd like to highlight this description of the work of Paul Silvia:

Writing is not easy. In his 2007 book, "How to Write a Lot: A Practical Guide to Productive Academic Writing," Paul Silvia, PhD, associate professor of psychology at the University of North Carolina at Greensboro, likens the tedious and occasionally agonizing process to the "grim business" of fixing a sewer or running a mortuary. The panic and frustration writers feel looking at a blank page with a deadline looming doesn't help, especially if you convince yourself you're creatively blocked.

"Naming something gives it object power," Silvia says. "People can overthink themselves into deep dark corners, and writer's block is a good example of that."

This likening of writing to grim business is a feeling I've had consistently with programming, and regularly with academic or professional writing as well. While I may look up to the creative work of many authors or developers, when the rubber hits the road and I'm not creating something of my own accord, I need to convince myself to just get it done. What stuck out to me is that both Lu and Sillup's articles have been about writing, and yet both resonated closely with my experience as a developer. Not just the traditional writing bits of my work like documentation, design, or comments, but the technical parts as well.

Once I started to think about this more carefully, I realized that a lot of advice from the two fields are isomorphic. The importance of outlines and revising your rough drafts, both steps that are easy to miss in deadline pressure. The struggle of trying to express an idea in just the right way, and sometimes having to accept that what you have is good enough. The eternal fight for self-discipline, bargaining with ourselves to move toward our goals. For improving, the value of reading others' work and getting peer feedback. Even the spontaneous creative bursts where the lines simply flow and you produce something beautiful. All these and many more are battles and triumphs that we face together.

Thinking of software this way has reframed how I think about productivity and improvement in my field, and made a lot of its associated advice seem more natural. Critically reading others' code isn't just a nice-to-have supplement to a programming education, but the best way to expose yourself to new styles and ideas that you might have never considered before. Books or rules of thumb alone aren't going to spur much improvement, we also need to get out there and write, consistently and at the edge of our comfort zone. And most importantly for myself, I've developed a newfound appreciation for separating the type of writing one does in their free time, and what one gets paid to write on a deadline.

Don't just Document Like a Scientist. Program like a writer.