Five programming tricks I learned from writers
Tags: career, tips
Published: 2019-12-02 14:32:23

---
title: Five programming tricks I learned from writers
published: true
description: Better writers and better programmers share things in common.
tags: career, tips
canonical_url: https://code.scottshipp.com/2019/12/02/five-programming-tricks-i-learned-from-writers/
cover_image: https://thepracticaldev.s3.amazonaws.com/i/4oc6gi2ooa6tgjsrsbxy.jpg
---

Writers are interesting people. They spend all their time with words. They obsess over the smallest details. They polish and revise. E.B. White once wrote that "english composition is . . . a way to spend one's days." Hemingway literally did just that. He worked on a single sentence until he was satisfied, and that often meant he finished just a sentence a day.

Programmers also spend a lot of time with words, and there's surprisingly more overlap to writing than most people think. Donald Knuth once observed that:

> "A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct." &mdash;Donald Knuth

I hold degrees in both Writing and Computer Science. I've also workshopped with professional writers and had both fiction and non-fiction published. Below I will mention five things that I learned from writers (and writing) that have also helped me write good code.

![Rubber ducks on a shelf](https://thepracticaldev.s3.amazonaws.com/i/fkl0loflrr5jvrll2wqk.jpg)

## 1. Writing code helps you understand your problem better.

Writers often encourage writing as a means to understanding and discovery. 

> "Writing is like driving at night in the fog. You can only see as far as your headlights, but you can make the whole trip that way." &mdash;E.L. Doctorow

One major idea I've taken from this is that writing code is often not the result but merely the journey. Write some code. Then throw it out and write it again a different way. Your solutions will become more elegant. 

I came across this great tweet from [Mario Fusco](https://dev.to/mariofusco) while I was writing this which summarizes this idea:

{% twitter 1195266353072103425 %}


## 2. Omit needless code.

> If I had more time, I would have written a shorter letter. &mdash;Mark Twain

By saying this, Twain meant that it's actually harder to write less. If you spend any time with editors, you begin to see that there are many unnecessary words in your writing. In _On Writing,_ Stephen King mentions that the first stories he submitted to a newspaper editor were usually cut in half under the editor's knife.

Writers revere a book called [_The Elements of Style_](https://en.wikipedia.org/wiki/The_Elements_of_Style) and the sentence, "Omit needless words" is actually one of its "rules." It is also an example of how to do just that.

Similarly, shorter code is usually clearer. If you have a Car class with a method to drive it, name the method `drive()` not `driveCar()`. Otherwise, you'll end up with redundant statements like `car.driveCar()`. 

And if a library or functional construct exists for something you want to do, use it. Don't loop through a collection to sum up some total. Stream it and sum.

Not:

```java
int totalPages = 0;
for(Chapter c : chapters) {
    totalPages += c.pageCount();
}
return totalPages;
```

But:

```java
return chapters.stream().mapToInt(Chapter::pageCount).sum();
```

Shorter code is more expressive.

![A rotary phone with a dial](https://thepracticaldev.s3.amazonaws.com/i/pdf3as2aszzsynw3bycu.jpg)

## 3. Know your audience

Writers also spend time to make sure they are speaking to a specific audience. An older generation of readers won't think twice about phrases like "dial him up." But phones don't have dials anymore and hardly anyone says that. Even so, it might still be appropriate for the latest issue of _AARP The Magazine._ 

It's all about _audience_. What is your code's audience? I think it's mostly the other programmers on your team, present and future. Donald Knuth has a great thought about this:

> Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. &mdash;Donald Knuth

Just like writing, code should look familiar to its audience. Whenever possible, it should adhere to known idioms and avoid clever tricks. That way there's fewer mental gymnastics necessary for your teammates to understand it. If your code doesn't clearly communicate what it's doing, are you a good coder? One way to improve code is to write it from the mindset that your best chance at getting the solution across to them is to write it in their language.

This is most important when naming classes, methods, and variables. Naming is famously one of the hardest parts of programming. It's mentioned in the famous joke:

> "There are two unsolved problems in computer science: cache invalidation, naming, and off-by-one errors." &mdash;Unknown

If everyone understands the word, _advertisement_, in a specific way, use it. But if there's ambiguity, find something more specific. Is it a print advertisement? Email? Text?

Although inelegant, using adjectives or modifiers to describe exactly which kind of advertising is meant (`EmailAdvertisement`) is one solution. Another is to think more deeply or broadly about the use case and find the word that the most people grasp intuitively. Maybe what the code is really modeling is an email marketing campaign. Perhaps there's a word that businesspeople in your company already use all the time for this. If everyone calls it an _email campaign,_ your code should too.

I've always been a fan of _domain-driven design_ for its concept of the [ubiquitous language](https://www.martinfowler.com/bliki/UbiquitousLanguage.html). 

> To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts. &mdash;Eric Evans

Writing code in your domain's ubiquitous language is one possible way of being specific and communicating to your audience. There are, of course, many others.

![Person using smartphone](https://thepracticaldev.s3.amazonaws.com/i/hq7w2zmxzht1ek6uzau4.jpg)


## 4. Write what you know

_Write what you know_ is a piece of advice every writer has heard. Yet it is usually misunderstood. You might think, _if I only write what I know, I must be writing memoir then?_ 

Melissa Donovan has a [great article](https://www.writingforward.com/writing-tips/writing-tips-write-what-you-know) about the _write what you know_ mantra, and she summarizes its meaning well:

> "To write what you know does not mean you only write about experiences you’ve had, people you’ve met, or places you’ve been. It means you use what you know about life, nature, and humanity as the foundation for your stories." &mdash;Melissa Donovan

How does that apply to code? It means code should manifest something of the real world. Code isn't its own separate entity. It lives alongside or maybe even inside your business context. As a software engineer, then, it is a reminder that most of your job is about understanding the user and their task. _Write what you know._ 


## 5. Write!

But the best thing I've learned from writers is simply to write! Write a lot! Most writers will tell you that you absolutely _must_ write every day if you want to be a great writer. Writing often is the number one piece of advice writers dispense. 

> "Write all the time. I believe in writing every day, at least a thousand words a day. We have a strange idea about writing: that it can be done, and done well, without a great deal of effort. Dancers practice every day, musicians practice every day, even when they are at the peak of their careers – especially then. Somehow, we don’t take writing as seriously. But writing – writing wonderfully – takes just as much dedication." &mdash; Theodora Goss 

This idea from Theodora Goss is also echoed in quotes from Ray Bradbury, T.S. Eliot, Orson Scott Card, and [many others](https://www.azquotes.com/quotes/topics/writing-every-day.html).

So write code. Write code all the time. Write code every day. Writing code takes dedication. Consider doing [code katas](http://codekata.com/) or going through [Project Euler](https://projecteuler.net/). Your code will show it, and your fellow programmers will appreciate it.

## Conclusion

I hope these programming tricks have been helpful. If you have any more that you've learned from writers or from writing, I'd love to read your comments below.

Happy (code) writing!