Content Writers, Programmers, we chase the same high

“I don’t know how they could write content all day, every day.” -Programmer

A programmer recently said the above comment in reference to a staff of writers^[1]The person is actually titled a Software Engineer, but I’m using “programmer” as a catch-all term for “people who write code.”. Both teams, the web development team and the content team, work to create websites for the same marketing company. I interpreted the comment as the programmer highlighting the gulf between what programmers do and what content writers do. As in, there’s no way I could write blog posts all day; I don’t see how anyone could. It’s not who I am. I’m not wired like that.

As someone who’s played in both the programmer^[2]Game developer, using GameMaker Studio (GML), Unity (C#), and Unreal Engine (Blueprints) and content writing^[3]Author of five books of fiction, lots of essays, and tons of blog posts sandboxes, my quick response was an attempt to bridge the gulf by correlating similarly motivated dopamine rushes. As a programmer, the thrill of writing a block of code that works just as expected is exalting. The beauty of elegantly written code is often a reward in-and-of itself. Same with writing copy. Finding just the right phrase, with balanced flow and impact, is its own reward. I spat out something to the effect of “content writers are thrilled by an elegant sentence in the same way programmers are thrilled by an elegant statement.”

“Thrilled” is probably not the exact word I used, but it’s one I’ve since settled on as it conveys a degree of satisfaction that both programmers and content writers chase. In this post I hope to help each side of this gulf, but programmers more directly, empathize with the other, and in turn perhaps eliminate the gulf entirely.

Let’s gather round the fire and Kumbaya the night away!

My method is a paragraph. My statement is a sentence. My variable types are the parts of speech. My IDE is a Google Doc.

Imagine this simple program. Its goal is to determine if the dangers of bear attacks have been properly expressed:

namespace AvoidBears
{
    class Program
    {

        static void Main(string[] args)
        {
            bool mainIdea = MostInteractions();
            float falseConfidence = SomeInteractions(mainIdea);
            bool hasLearned = DontDoThis(falseConfidence);

            Console.WriteLine("The reader has learned that bears are dangerous: " + hasLearned);
        }

        static bool MostInteractions()
        {
            bool isMostlySafe = true;
            return isMostlySafe;
        }

        static float SomeInteractions(bool isSafe)
        {
            float falselyConfidentInWilderness;
            if (isSafe == true)
            {
                falselyConfidentInWilderness = 100f;
            }
            else
            {
                falselyConfidentInWilderness = 0.2f;
            }
            return falselyConfidentInWilderness;
        }

        static bool DontDoThis(float falseConfidenceLevel)
        {
            bool hasLearnedBearsAreDangerous;
            if (falseConfidenceLevel >= 100.0f)
            {
                hasLearnedBearsAreDangerous = false;
            }
            else
            {
                hasLearnedBearsAreDangerous = true;
            }
            return hasLearnedBearsAreDangerous;
        }
    }
}

Here we have three methods. Each takes in a return value from the previous method to ultimately determine the value of hasLearnedBearsAreDangerous.

Now, imagine these methods are actually paragraphs of text in a blog post about the dangers of bear attacks. Paragraphs, much like methods, require input (ie, ideas from previous paragraphs) and deliver a return value (ie, a new or expanded-upon idea). Both programming and content writing use blocks (methods/paragraphs) to inform functionality of other blocks. If the goal of the example content piece above were to properly teach the reader about the dangers of bears, it would fail (hasLearnedBearsAreDangerous returns false).

The similarities don’t end at the method/paragraph level:

• Both start with an end-goal in mind.
• Both rely on revisions (refactoring/editing) to craft a more elegant solution.
• Both rely on adjusting values (variables/words) to inform the blocks.
• Both are strict (syntax/syntax^[4]See, even those words are the same. Kumbaya!) so as to ensure proper presentation (compilation/reader understanding)

The Unabstactability of written language

A piece of written copy is often designed to teach or entertain the non-binary mental state of a person. A piece of written code is designed to inform the binary needs of a computer. A program either works or it doesn’t, based on how well the problem was abstracted. A piece of content, however, can almost never be absolutely abstracted. This massive difference is where, I think, a programmer might see content writing as something they couldn’t do “all day, every day.” This unabstractability can be uncomfortable for many people^[5]Or maybe some people simply find content writing boring. That’s fair. I’ve been bored with it before..

Unabstractability is ingrained in the very fabric of human language. It’s why we have so many words for single concepts yet still it seems we never have enough words. Throw in social malleability, and the slang it spawns, and you’ve got even more layers of movement and un-absoluteness.

Declaration isn’t enough

Another way to look at the unabstractability of written language is to consider the idea of memory. In programming, if we want the computer to remember something, we first create a space (ie, variable) for that memory by declaring the space. Then we tell the computer what value to remember by instantiating that space. Once that space is declared and instantiated, the computer will remember it until we tell it to forget it. This consistency is comforting. This absoluteness makes creating a “code narrative” dependable.

In the world of content writing, declaration isn’t always enough. A content writing variable isn’t simply given memory (in the RAM), it has got to fight for memory (in a human brain). Think of the way a short sentence among a paragraph of long sentences stands out. Or that, in a paragraph of dull prose, I might suddenly tell you that last night I shit out an entire Donatello action figure. The information in that short or vivid sentence is going to be much easier to retrieve in a later paragraph/function.

Think of it this way: a vivid detail is globally scoped. A dull detail is locally scoped. Will you remember Donatello’s headless body and its confusing journey through my digestive tract? For sure. Will you remember that the fifth word in this paragraph is “way”? Probably not. At least not once we move on to a new method/paragraph.

Our tasks are different, our skills are different, but our means are the same

Programming and content writing initially seem like functions at opposite hemispheres of our brain. Though programmers will insist that creativity is part of programming, and content writers will insist that structure is part of content writing, I have witnessed a reductive division between the “left brainers” and “right brainers.” But that division isn’t actually so static. The gulf isn’t so wide.

Grab your guitars and your synthesizers, your colorful coats and your survivalist blankets, and let’s sing together around the campfire.

Photo by Courtnie Tosana on Unsplash