5 Ways Coding & Writing Are The Same
We’ve had a number of librarians, designers and writers joining our Code Like a Girl Python classes. This made me consider how to make writing code less intimidating to those of us who do not have a background in STEM. That, in turn, made me realize that there is more in common between writing code and writing words than I had realized. I’m definitely open to hearing your thoughts on what commonalities you see between development and other skill sets. I think that for many people, the barrier of entry is not understanding how their current skills translate into the new skill they are learning. I hope this helps some of those people to make these connections.
They both need fundamentals of craft paired with creativity.
When you break down both tasks, they take a strong proficiency in basic building blocks before you can execute complex processes. You can have the best idea ever for a young adult series of novels. That idea can not be executed well if you drop too many commas or don’t understand how important point of view is to your piece. It takes huge amounts of drafting and rewriting to create strong copy. You can’t execute on your brilliant, creative story-line if you do not understand the fundamentals of sentence and story structure.
The same thing goes for coding. You can have a great idea for a software or process, but you don’t get to jump in. There are a thousand opportunities to self-publish your terrible novel, just like there are a thousand services online that promise to build your app or website or software solution in ten clicks. The end result is most likely not going to be good, and is overall, someone else’s work. You have to be terrible at coding before you can be great at it. It takes having the fundamentals of lists and loops and processes before you can create something larger and functional.
Novices are obvious, experts are seamless.
Clumsy writing confuses the reader. Clumsy code confuses the computer. We’ve all been absorbed into a piece of content (a book, a movie, or an essay) only to trip over a sentence, a piece of dialogue, or a description that was poorly written or didn’t ring true. This pitches you out of the world the writer created and stops all processing of the story. A good writer guides the reader through their content. They keep them focused and absorbed into the story through strong writing. The same thing happens in programming, only, instead of the character’s eyes all of a sudden being the wrong color or the dialogue being stilted, it’s a loop that is poorly written or a semi-colon that is missing.
This particular consideration has helped me to understand why things aren’t working in the projects I build. Rather than getting frustrated at myself for not understanding or at the error messages for being too vague, I consider the computer a reader. Reader’s don’t always have an exact answer as to why they didn’t like something. Sometimes it is a general feel. Sometimes I am not writing to the reader. When this happens, I consider how I often change text depending on my anticipated reader. I don’t get frustrated by that process or those rewrites. Considering the computer as a reader helps me decrease my frustration when editing and fixing code.
Both answer to humans and machines.
As a writer, understanding the structure of my content helps my search engine optimization. By dividing content into headers, paragraphs and lists and by providing relevant links, I make it easier for the reader to understand, but as a secondary benefit, I make it easier for machines to understand. I write for people but I provide etiquette that allows machines to also understand my content.
Developers do the exact same thing; their primary audience and secondary audience are simply flipped. Their goal is to write content that is executable and understandable by machines. They also need to consider the people that will read and edit their code at later times. Their code structure and comment lines are imperative to make it understandable to human eyes.
Perceptions: Solitude versus community.
Pop culture and history give us the idea that both writers and developers sit alone in rooms pouring their brilliance through their keyboard of choice. Writers are supposed to be accompanied by a bottle of whiskey. Programmers, by a can of Monster energy drink.
And yeah, the actual creation of the first draft of our product is pretty solitary. You need to be the person to translate your idea from concept to items on a page (or in a text editor). But neither of these skills work well in a vacuum. You need other eyes, editors, people to go over your code or copy, groups to discuss how to get from point A to point B, people to tell you that you took way too many pages or lines of code to execute your goal, people to offer suggestions and move you through roadblocks.
Both writers and developers become much stronger by working with groups in their community. Taking suggestions and criticism are paramount to success in both fields. The perception for both skills is long periods of isolation and then a top-notch product released to the world. In reality, it is more of a write, show, edit, write, show, edit, write, show, edit, release version one, have people tell you about issues you can’t believe you missed, write, show, edit, release again.
Coding Languages & Stylized Writing
People often ask which coding language they should learn. The most common answer I hear is “The one that will let you build a project you are excited about.” Coding languages have many commonalities, but also many differences. So does stylized writing.
Consider the structure, word choice and language between a persuasive essay and comedy sketch. They both may end up influencing how I feel about a specific topic, but they are completely different pieces of writing with different audiences, structures, goals and rules for the genre. Think blog post vs academic paper, Twitter post vs young adult novel, dystopian future sci-fi versus historical fiction novels. All need the same understanding of basic structure, but the execution of each will be very different and focus on the audience, the best platform to present, and rules that are specific to the platform and genre.
You can think of coding languages the same way. Some are meant to communicate between machines, some are meant to trigger actions between hardware, some are better used for organizing information in a hierarchy, some are easily accessible to novices. The medium, end-goal and audience are helpful in understanding which language is most applicable.
I’ve found that telling people how the skills they already have can translate into the new skill set they want to develop has helped them to feel a bit less intimidated. What do you think? What other skills overlap with development? How would you let someone who doesn’t have a STEM background know that they can learn to code?