The English Major’s Guide to Writing Code

Uncategorized
mead-notebook

Post Tags

The Oxford comma is a perfect example of what frustrated people about English class. Students were once taught that no comma was necessary before the conjunction in a series. If your brain has long since rejected grammar terminology to make room for more frequently used information, here’s an example:

The process of writing is thrilling, exciting and fun.

See? No comma before “and.”

Then it was decided the Oxford comma was a great idea, and American children were taught that it’s mandatory:

The process of writing is never dull, boring, or frustrating.

Now we have a comma before “or.”

How is it possible to thrive in a system where the rules are in flux? And what about the papers with perfect grammar that were still marked down for something seemingly subjective like “word choice”?

Many people getting started in web development assume that that world of subjectivity and ever-changing rules are behind them, but as it turns out, writing code is a lot like writing essays.

Writing Code is a Language Art

I’ll start with the obvious. English is a language. So are HTML, CSS, Javascript, PHP, and others. They are markup, style sheets, and programming languages (respectively) and involve their own unique vocabularies, mechanics, and semantics. In spoken languages, there are grammar rules that help you organize words so that other people understand you. In code, you’re organizing information into an order that computers can understand.

Because of these parallels, many of the best practices you learned in ENG 101 for developing your essay writing skills also apply to your code writing skills. Let’s look at a few of these.

1) Find good reference books and consult them often.

Dictionaries and thesauri are quick references when you’re trying to find the right word or—if only more students did this—making sure that the “right word” means exactly what you think it does. Research papers require style guides like APA and MLA. These are frameworks for consistent documentation that ensure scholars and researchers get credit for their work.

Some quick references in the coding world are the Mozilla Developer Network, PHP Manual, or CSS Tricks. To my knowledge, there are no real equivalents to MLA in development, but there are various schools of thought on how code should be organized or executed. For instance, some developers recommend specific and strict naming conventions. These differences in opinion are nothing to stress about. The point is just to figure out what works for you and be consistent with it.

2) Have a strong thesis statement and outline before you start.

In ENG 101, outlines felt like writing a short version of a paper before writing the real version, and if I’m honest with you, I wasn’t the best outliner myself. It’s good to have a plan before you sit down to start coding, though. The plan can be as simple as a sketch of the final project with the various sectioning elements noted.

A simple coding project might not require an outline beforehand, but every coding project, like every good writing assignment, should have a strong and specific thesis. In high school we’re taught that a thesis statement is “what the paper is about,” but that is a better definition for the whole introduction paragraph. The thesis needs to clearly explain why you are discussing the subject at all. What is the reader going to gain by reading this specific paper?

A thesis for a coding project is comprised of the answer to many possible questions. What is the ultimate goal of this project? Will it be expanded in the future? Will it be maintained by developers or people with fewer technical skills? Will it be viewed on a touchscreen or a monitor? The answers to questions like these (and others) will affect your coding strategy. It’s important to keep the big picture goal of the end product in mind, even when coding the h3 elements on a simple widget.

3) Keep your writing concise and straightforward.

This comes down to two basic best practices: don’t use multiple words when you can use one and don’t use jargon or complicated terms when a simple word will work. If you’re going to get long-winded and fancy, you should have a very good reason for it.

These same principles apply directly to coding. You don’t want lines of unnecessary code cluttering up your text editor, so streamlining your code keeps it light and easier to manage. Best practices like DRY (Don’t Repeat Yourself) is an example of this principle, as well as the habit of refactoring code, a process that rearranges code for efficiency without making noticeable changes to the final product.

Writing is More Than Following Rules

Writing has lots of rules, and many of those rules should be respected. A good writer, though, leverages those rules in a way that gives her freedom within constraints. She recognizes which rules to obey and which ones to bend to get the desired outcome. She knows how to create something fresh and compelling through and despite the conventions she has mastered.

Somerset Maugham captures this tension between rules and freedom in this quote: “There are three rules for writing a novel. Unfortunately, no one knows what they are.” The deeper you get into coding, the more you see this applies in the development world as well. You’ll see unending lists of “always” and “nevers,” but don’t let that discourage you from plowing forward out of fear of not doing things “the right way”.

When writing words or code, the best thing you can do is master the basic mechanics and terminology of each and build projects with confidence, knowing that as long as you’re practicing your craft, you’re moving in the right direction.

Whether or not to use the Oxford comma is up to you.

Image Credit: autopoiet

Comments are closed.