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.
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.