>What Writers Can Learn from Coders
Recently I started learning how to write snippets of Ruby code just to see what the fuss was all about. By around lesson 12, I began to understand the strange work habits of coders.
Some coders, like writers, prefer to work alone. They write a draft. They figure out how to improve the draft. They seek help from a few forums but largely, they work in private embracing the struggle.
However, there’s another set—coders who work as a group. Let’s call it “social coding”.
How it works
When a coder writes a block of code (the source code), he places it in a code repository. He’s now the author. The source code is similar to the first draft of an essay. Other coders are allowed to ‘fork’ the repository (download the source code) and play with it. They will notify the author if they believe they’ve made an improvement. Which could mean using a new command (using better words) or refactoring the code (rewriting a paragraph with fewer words). If the author likes what he sees, he will merge the code into his source code.
The author always has the last say on what goes in. He can reject a contribution for any reason.
Sharing is Hard
Now, writers, unlike coders, can be possessive and territorial. Few writers would want other writers mucking around with their prose. Which is precisely why I struggled with coding. Part of the process in the code tutorials (Learn Ruby the Hard Wayby Zed Shaw) requires that you share your code online. I don’t mind a couple of people looking at my code. But just about anyone? I don’t know if I feel secure enough for that sort of thing.
Coders don’t have that problem. They let go. That’s just how they were raised. Weird.
“I think developers are comfortable with sharing since most developers know they’re not the best coders,” says James De Jesus, director of creative development at AKQA. “They approach it with a mindset that things can always be improved, which makes sharing easier since they believe that the badass developer they follow on Twitter might take a look and refactor bits for them.”
While collaborative coding is helpful, it’s also a humbling process.
“Lots of times, the sharing is preceded by apologies about how poorly the code is structured and how hard it is to read,” says James.
But by allowing others to fork their repository, the code gets better and tested for bugs and efficiency. The author also gets to deploy a project in half the time.
Despite the collaborative spirit, developers don’t always want to share the spotlight and are often trying to carve out names for themselves online. Some developers I spoke to said they too, like writers, have an ego about their work. They’ve just learned how to lay aside their ego in favor of seeing their work see the light of day faster. You can’t argue this process has helped put certain web technologies ahead of proprietary closed-source ones. Will it work with writing?
Let’s Experiment
When other coders started forking my repository, I felt uneasy. Then I reminded myself that copywriters were just raised differently. We want to be the lone rangers. We don’t want ten people working on our document. How will anyone know who wrote it? How will we get our next job?
But what if I said, “Okay, I am going to let go. Let’s just see what happens."
I’d like you to join me in a writing experiment.
RULES (that take inspiration from the world of coding):
Any writer has the permission to pick up this unfinished essay and modify it.
If you make a change, add a comment with a hash tag.
If I like the change you’ve made, I will update it on my original document and list you as a contributor. If I don’t, then you shouldn’t feel bad.
I thought about tracking changes on a word doc but it would quickly begin to look messy. To help with version control (another coder quirk) the essay can be edited on Yammer if you are an AKQA employee.
Let’s see how this essay turns out after a few weeks.
What success looks like:
1. The essay gets better.
2. It gets completed faster than I originally intended.
3. We don’t have arguments over who did what.
The Results
This section was added after I stopped accepting contributions during the final week. Which may explain the slip shod writing.
Success was based on three parameters.
Did the essay get better than I originally intended?
Yes. Not only did the prose improve, new ideas were added which enriched the original material.
Did it get completed faster than I originally intended?
No. My goal was three weeks. It took six. Shame. The mistake was I didn’t set a date of publication. Also writers aren’t used to a preposterous idea like collaborative writing. So why would anyone contribute? Contribution trickled in slowly.
Did we argue over who did what?
No. The final tally—Contributors:8 Merged: 5
I didn’t receive any complaints about the way I used contributions. I modified a few I pieces before merging but that was part of the deal, wasn’t it? If you feel treated unfairly, please let me know.
Last words
The purpose of the experiment was to test if drawing upon the writing experience of multiple writers could enrich a thought. But who qualifies as a writer? The typewriter turned everyone a writer. Just like Instagram turned everyone a photographer. And Rottentomatoes turned everyone into a movie critic. I sent this out to the AKQA Writers group. But engaged the coders as well. I think as long as the contributor’s pool is well defined, it’s okay to get feedback from non-professional writers. Most people will contribute only if they feel they can improve upon an idea.
Some contributions obviously won’t be right. Since this isn’t a Wikipedia-like exercise, where people insert facts, the onus of structuring an argument (quality assurance) is on the author. The author must keep an eye on tone, voice and clarity of the overall thought.
This type of coder inspired process may work for long copy writing. Essays, press releases, blog posts where there’s space for building an argument. Perhaps someone needs to build a proper github for collaborative writing. Although I don’t think the challenge is building a new app. Right now our writer insecurities may prevent us from embracing the practice in the first place. I’m not even sure if I’m ready. But again, this is the sort of ending that can be improved.
Author
Vinit Patil
Contributors (Thanks for playing)
Thea Boodhoo
Alan Brimm
James de Jesus
Emily Ostendorf
Bob Hall
