5 Ways Writing Can Help Your Coding
Science and humanities are often thought of as mutually exclusive. Even when the two overlap, it’s usually in terms of science influencing humanities, such as mathematically inspired paintings, or the application of physics and chemistry in sculpture; we hardly ever talk about the opposite direction. In this article, I’m going to share my experiences in marrying the fields of prose writing and programming; specifically, the ways practicing the former can help you develop the latter.
When I was eighteen, and it was time to file my university applications, my mother and I were at an impasse. I insisted that I wanted to be an architect (as in, brick and mortar, not software), while she was convinced I’d be much happier in computer science. A compromise was reached when I didn’t get into either, and landed in my safety school majoring in English. Some problems just have a way of solving themselves.
For a long time, I regarded my brief excursion into English as just that: an interesting, but ultimately inconsequential detour. It was almost ten years later, when I finally gave CS a second shot and became a professional developer, that I realized how enriching it was. Time and again, as I sat hunched over my keyboard, the memories of my English writing classes kept creeping back to me, and I couldn’t help comparing those experiences to my current situation.
Here are five of the lessons I’ve learned so far.
Know what you’re trying to do
There’s a ground rule in academic writing that if you can’t sum up your essay in one sentence, then you don’t know what you’re talking about. If that sounds needlessly strict at first, that’s because it is. It’s one of those rules that aren’t really about the end result. The real purpose behind it is to encourage a mindset that is fundamental to solid writing: Know what your point is, and stick to it.
If you’re writing an essay, you probably have a lot to say about the subject. That’s why you decided to write in the first place. You have a dozen topics in mind, and you might feel that you absolutely must talk about every one of them, otherwise it will just be incomplete. One of the first lessons writers have to learn is to ask the question: “Yes, I want to talk about this topic — but do I need to?”
In coding, this ties into a concept I like to call “Mr. Heckles scoping”, after the beloved bit character from the TV series Friends. Mr. Heckles, the main characters’ downstairs neighbor, would pop up two or three times a season to knock on their door, followed by a conversation that went something like this:
Mr. Heckles: You’re being loud. My cats can’t sleep.
Monica: You don’t have cats.
Mr. Heckles: I could have cats.
I myself have both encountered and demonstrated this attitude far more times than I’d like to remember. Building an image editor backend? Better make sure it supports TIFF, PCX, and all the other formats nobody uses! Making a graphics engine for my game? Let’s add two more layers of abstraction, in case I change my mind and switch from sprites to 3D models! Of course, I’m not going to. I don’t even know anything about OpenGL. But I could.
As developers, we are constantly reminded to keep our code modular, responsive, cross-platform, future-proof, and other buzzwords. Those are often completely sensible goals. The balancing act lies in not letting yourself be distracted by requirements that aren’t even there. Practicing effective writing can teach you to focus on what your actual purpose is, and deliver that. Everything else is just nonexistent cats.
Stop worrying and get started
If you’ve spent any amount of time on Facebook, you’ve probably come across one of those riddles that come with a caption like, “Adults take twenty minutes to solve this, six year olds take twenty seconds!” Most of these only serve to remind me that I must have been dumb as a brick at that age, because I sure as hail wouldn’t have figured them out on my own. However, there was one that did stick with me.
The task is simple enough: draw three lines to connect the matching letters. The lines cannot cross each other, the boundary of the rectangle, or any of the letters they’re not connecting (None of them need to be in the shape of a kitten, though). Feel free to ponder for a while, but just to move things along, here’s the solution:
The reason I’m willing to believe that kids solve this faster than adults is because kids worry so much less about making mistakes. Instead of staring at the image for minutes, trying to visualize the solution before they draw a single line, they just grab the first marker their tiny hands can reach, and jump in. And really, once any two lines are already there, the rest of it is self-evident.
Getting started is one of the hardest parts of writing, because the mere question of where to start can feel agonizing. Over the years, writers have come up with countless methods to help take those first few steps, and one of my most exciting realizations was how many of them work for writing code as well. Do you like to lay down the basics first and grow from there? Try the snowflake method. Do you have a vision for the result, but not much idea about the deeper parts? The flashlight method could help. Are there some fixed points you have to include, but otherwise plenty of wiggle room? Set pieces to the rescue.
Practicing as a writer and researching outlining techniques (such as the ones above) can help you find new ways to stop overthinking and just get to work. Most of the time you will find that once the first few lines are there, the rest comes so much easier.
Don’t be clever for cleverness’ sake
I have reviewed a fair number of essays for my friends and coworkers, and any one of them can tell you one thing: I have never criticized anyone for making their sentences too simple.
When you’re a learning writer, you may be tempted to think that good writing means fancy words and elaborate phrasing. I know I certainly did. I would add flourishes like “for the reason that” instead of a plain “because”, for the reason that I thought it would make my writing look smart. I padded out my paragraphs with metaphors as useless as a blind man’s binoculars. It took me years to learn how much value lies in simplicity.
As a classic example, take the following two code snippets:
// Snippet Afor (let i = 0; i < buffer.length; i++) {
buffer[i] = 0;
}// Snippet Bfor (let i = 0, l = buffer.length; i < l; buffer[i++] = 0);
Code that follows the principles of the second example (i.e. use as many shortcuts and short-circuits as you can) is often hailed as “slick” or “elegant”, and speaks of the developer’s deep understanding of the language. The problem is, it renders the code much more difficult for an outsider to read, while offering no real benefit.
Try to pause every now and then, and look at your work with a stranger’s eyes; preferably after at least a good night’s sleep. Does it tell a clear enough story? Are your API signatures intuitive? How well could someone use your code without you to explain it? Practicing clean, straightforward writing can help you develop the instinct for clean, straightforward coding. A little less impressive, a lot easier on whoever fills in for you on your sick day.
Be your own critic
A special flavor of writing is the argumentative essay. These are the pieces where you don’t just describe something, but make a claim and follow it up with well-structured facts. Argumentative essays are subject to much stricter rules than other genres, to ensure that the line of reasoning is fair and unbiased. One such requirement is the inclusion of refutation.
Refutation is a brief segment in which you stop to reflect upon the arguments you have assembled, and address the points where you think a skeptical reader might disagree (e.g. “One might worry that my suggestion of company-supplied heroin can lead to a dip in performance.”). Most of the time, you will offer counterarguments, or assure the reader that their concerns are unwarranted. However, this needn’t always be the case. You may very well make some compromises, or even flat-out admit that you don’t know the definitive answer. The point of refutation isn’t to obliterate your opponent’s opinion; it’s to show that you considered them when forming your own.
We programmers live in a world of patterns. Well-established rules and conventions govern our work, based on billions of hours of collective experience. Still, we often find that a particular situation calls for a solution that our patterns just don’t cover. When going against the grain like this, it’s important to be able to step back and reflect on your decisions. What concerns might an outsider have about your work, and how would you address them?
When all you see is code all day, it’s easy to forget that development is essentially a form of communication. Everything you write is an expression of your own world view, and your attitude to the existing patterns. A database macro for a quarterly sales report might not feel like it’s up there with Shakespeare’s 130th, but when another human — be it a developer or an end user — needs to interact with it, they are indirectly interacting with you. And that interaction can involve disagreement.
The goal here isn’t to assert your own right by whatever means; nor is it to drive yourself into constant insecurity. It’s simply to be open. Practicing refutation can help you develop a need for fairness and empathy, especially when working with others.
Learn to let go
There’s a widely held misconception about the writing process in general, one that stems from the very term itself. Ninety per cent of the time, when we talk about “writing”, we refer to the physical act of recording words on a page or a screen. We could hardly blame anyone, then, for thinking that when a writer “writes” something, they do just that: they sit down and write the words. If you ask any of them if the above is true, then rest assured: the moment they stop convulsing in laughter, they will tell you that it’s not.
The writing process begins with a version known as the first draft, also called the rough draft. It’s called a draft, because it’s not the finished work, and it’s called rough, because the word most writers would rather use is not welcome in polite conversation. First drafts are never even close to the finished product. Huge chunks of text are deleted, moved around, split in two or frankensteined into one. One of the hardest, yet most fundamental lessons a writer has to learn is that you shouldn’t become emotionally attached to any part of your work, because you never know when you’ll have to cut it.
Take this article for example. When I planned it out, I had an entire additional section in there. The order of the points was different, and I had a humorous illustration in mind for each one. Then I got started, and slowly realized that my original direction just wasn’t what I needed. I dropped the illustrations, re-wrote several parts, moved them around, and just kept hammering at it until it came together. Of course, the essence of the first draft is still in there, but the end result is vastly different.
This is nothing new in any walk of life. Economics calls it the sunk cost fallacy: the more time and energy we put into a project, the more reluctant we are to admit when all or part of it needs to be thrown out. As a developer, writing can help you remind yourself that changing direction doesn’t always mean someone didn’t do enough planning. Change is often a natural consequence of the development process, as you gain a deeper understanding of your own work. Save yourself time and grief by recognizing when something just isn’t needed any more.
I am by no means trying to pass off these bits as some sort of arcane wisdom one can only gain through writing. There’s a good chance you’ve already heard or figured out most of it in some other context, with or without realizing. What I’m hoping to offer is a new perspective of looking at what we do day to day, and how we can learn new patterns or practice existing ones in seemingly unrelated fields. Even if you don’t take up writing tomorrow, perhaps you’ll find inspiration in some other hobby you already have.
