Writing and Programming: More alike than you may think (Part 2)

Over the past year or so, I’ve become keenly interested in the connections between technology and the humanities. Why do we persist in separating the two?  Are they really so foreign that they can’t be brought together?  What can we carry over from one discipline to improve the other? How can we begin to blend the lines of distinction between the two disciplines to strengthen what we do as writers, usability researchers, designers, or developers?

These are huge questions to tackle, and I can’t even come close to scratching the surface. But I do have a few ideas of my own, based on my personal experience over the past 6 or 7 years moving back and forth between the two camps.

Yesterday I began a list that presents some of the similarities I’ve noticed between programming and writing.  This post is the second half of that list.

4. Understand that being a programmer and knowing how to program are two very different things. The same principle applies to writing. 

Since I began teaching, I’ve observed students coming through my classroom who will never be considered “writers.” And by that, I don’t mean they lack the ability to write clearly and expressively, using logical organization and correct grammar. These student actually write very, very well and submit excellent work. My point is they won’t be moving into professions where their responsibilities are focused solely on producing publishable documents. Yes, writing may make up a part of their job… but they aren’t employed to be writers.

Writing is what they do, not who they are.

From a personal perspective, I’m trying to develop skills in HTML, CSS, Javascript, and Ruby.  But I doubt I’ll become a web designer or applications developer–at least not if I want to pay my rent and by groceries.  My goal is not to become a programmer, my goal is to understand programming. I won’t be answering job postings for “Web Applications Developer,” but I will have a better understanding of back-end development, project management, work flow.  I’ll know how to work more effectively with developers and design teams so I can do the things I actually am good at: usability and communication.

5. Use an agile/iterative approach. 

From my understanding (which I admit is limited), an agile approach to software development pushes developers to produce a complete “working” version within the timeframe of just a few weeks. The goal is to have a complete version they can cycle back through several iterations, working out kinks and adding additional features in response to user testing.  This process encourages developers to make incremental improvements to their programs as they go, working in stages that allow them to stop, evaluate their work, and make changes, before moving on to the next phase of development.

Likewise, writing is definitely not a linear process–well, good writing isn’t.  If you approach writing from the viewpoint that you need each sentence and each paragraph to be perfect before moving on to the next, you’ll never actually finish. That’s why I force strongly encourage my students to write multiple drafts in my composition courses.

During in-class writing workshops, I tell my students that I’d rather they bring in a crappy full draft than 2 or 3 well-written pages. Sometimes this means full paragraphs mixed in with bulleted notes or questions–that’s great! I just want their ideas out on paper so we can look at their argument, overall organization, and thought process. They always see measurable improvement from one draft to the next.

Until you get the words out of your head and onto paper (no matter how under-developed and messy it may seem), you can’t get the constructive feedback that will help you move forward to the next phase of production draft.

6. Keep your writing/coding clean and precise. 

In the context of writing, this idea is pretty simple. We prize writing that is concise, complete, easy to understand, and well-organized.  If your writing is clear and organized, you are more likely to get your point across and less likely to confuse readers.

I love this example from Handbook of Technical Writing: 

Original Sentence: It is the policy of the company to provide the proper equipment to enable each employee to conduct the telephonic communication necessary to discharge his responsibilies; such should not be utilized for personal communications.

Huh?? I had to stop somewhere in the middle and start again!  Let’s try this instead:

Rewritten Sentence: Your telephone is provided for company business; do not use it for personal calls.

Much better. Wouldn’t you say?

So how does this relate to programming? Very well, actually. The cleaner and simpler your code is, the less prone it is to bugs.  And when you do encounter bugs (which you will), you’ll be able to find them and fix them more quickly.

I have a few others I could add to the list, but I felt like they might be a bit forced. My purpose behind these posts is pull out the most natural similarities between programming and writing. 

I have a few thoughts I’m going to wrap up with tomorrow, but until then… what do you think?  Is there anything else I could add to this list? Or do you think all of this is too much of a stretch? 

And if you haven’t yet, check out the first part of the list.

Advertisements

2 thoughts on “Writing and Programming: More alike than you may think (Part 2)

  1. Pingback: Writing and Programming: More alike than you may think (Part 1) | Laurissa Wolfram

  2. Pingback: Writing and Programming: More alike than you may think (Part 3) | Laurissa Wolfram

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s