5 Lessons Writers Can Learn From Programmers


When I’m not writing fiction, I’m writing code at a successful digital agency (I mean I get to sleep and eat and other stuff too you know). I’ve started to notice that, even though the two things are worlds apart, there are a lot of skills and ideas that I’ve been able to transfer between them. I’ve also found a lot of other writers are involved in the grim underworld of IT as well, so for them and everyone else, here are some insights I’d like to share.

Release early and iterate
This is Google’s idealogy for software development – get something out there that is simple and robust -then- start adding in extra features and making altertations based on real user feedback. The same applies for your writing – we live in an electronic world where, with the exception of submissions to agents and publishers, nothing is set in stone. You’ve already got a blog right? Forget making it look pretty, just start firing your work up there and telling people about it – worry about having a really cool logo later. And don’t worry about making mistakes or being less than perfect in your work – people will tell you what you’re doing right or doing wrong and you can then go back and refine what you’ve already done or feed that lesson into whatever you’re working on next. Similarly for novelists, don’t keep your story secret and hide it away from the world until you’re convinced it’s perfect – start getting people your trust to read it fairly early on (not too early mind). If it’s not up to scratch then you can always go back and rewrite it – something which is much easier to do before you’ve whacked out another 10 chapters that don’t quite fit after it. Get feedback, learn lessons and continually feed that back into your work.

Backup backup backup
This one’s a great adage of Computer Science teachers and lecturers – back up everything at least once. Just like when your power or internet goes down, you don’t realise what you’ve got until it’s gone. How heart-breaking will it be if your laptop dies or your memory stick gets lost along with what was the only copy of your 60k words of lovingly crafted story? Trust me – you want to have a backup. The simplest way of achieving this to regularly save a copy of your document to a flash drive or e-mail self copies but you could also try using Google Docs, that way all your work is stored safely online (in the cloud) and you can access it from anywhere with an internet connection. Or my personal recommendation is DropBox – this brilliant, service will automatically make online copies of any files and folders from a set location on your computer. The beauty of this is that once it’s setup you don’t have to do anything else and further more every iteration of yours files are stored, so you’ve got the added option of rolling back any unwanted changes you might have made.

Never test your own work
This is one that every developer knows but most will still ignore. Don’t test your own work, if you’ve been staring at the same application or web-page for hours on end then you’re simply not going to catch every error and things that make perfect sense to you aren’t necessarily be the same for everyone else. The solution of course to always get a different person to go over your finished product with a fine-tooth comb and report back to you. The same goes for writing. You’re far too close to your work to see (or admit) every problem and the chances are if you didn’t know how to spell that word properly first time round, you won’t when going through it again. I’m not saying don’t edit/analyse your own writing at all but make sure you get at least one other person to go through it for you. Bonus tip: Test on different browsers. Those of us that develop for the world wide web are only too familiar with the fact that different web browsers render pages in slighty different ways. You could spend hours building a web page which looks great in Firefox but falls apart when you finally test it in Internet Explorer. The moral of the story? Get as many different people to go over your work as possible, don’t just rely on the same person all the time. While one reader happens to get what you said in that overly elaborate sentence, another might flag up that there’s an issue there which would have otherwise been missed. Also if someone constantly loves and praises your work, make sure you’re getting the opinion of someone else unafraid to be brutally honest with you.

Bug tracking
Once your manuscript gets over a certain size you’re going to start finding things that are not necessarily wrong, but perhaps you may want to research more and come back to, or in hindsight needs reworded, added to, etc. These sorts of things are going to start stacking up and won’t necessarily come to you whilst sitting in front of the document so it’s a good idea to start keeping a list and getting into the habit of noting these issues down straight away, otherwise things will start slipping through the cracks. The added bonus of this approach is the feeling of satisfaction as you start scoring items off again and grinding that list back down. This approach is widely formalised in the IT industry with huge pieces of software being available for the recording, assigning and tracking of bugs/issues but there are also a variety of simpler, free tools that writers can take advantage of: Remember the Milk and Thymer being two good examples.

Design THEN build
This one of course refers to that greatest sin of writing – making it up as you go along. We’ve all done it at some point and it’s a hard habit to shake off. Software developers suffer the same flaw – just running off and writing code without first figuring out if they’re even doing the right thing. Various processes have been put in place to correct this process, the most famous of which is the Waterfall Model which is broken into the following stages:

  • Requirements – Put together a detailed document of what exactly you are trying to achieve. What is your story? What do you want to convey to the reader? Classic adventure? A moral stance of global warming? Your distant relationship with your father? And how are you going to achieve that goal? Zombies? Time travel? Romance?
  • Design – Now start planning. Plan everything. Every character and every aspect of their personality. Draw maps of your locations, timelines of events both before and after the actual story. Don’t be shy about over-quantifying your story here, it might feel a little like tearing the soul out of your work but it really will avoid so many dead-ends up and gaping voids later in the process (and of course it can all be changed later – but shhh, don’t tell anyone!)
  • Implementation – Now you can start writing the thing. Seriously, go ahead, I’m not going to tell you off now.
  • Verification – Now read it back, get your friend to read it as well, and your neighbour and your cousin bob and people from your writing group. Start getting feedback and start putting it to work.

  • Maintenance – Umm now this stage doesn’t really work so much fiction-writing so instead of saying “maintain your novel” I’m going to say “maintain your setting and characters” – try doing news things with them, let them evolve, hell even recycle them (Stephen King does that all the time).

So there you go – five simple things. None of them are really rocket science, just refined, proven ways of facing up to the things you don’t really want to do. Does anyone else have any handy tips from their “other life”?

Title image courtesy danzen

Advertisements
Published in: on September 20, 2010 at 8:28 PM  Comments (13)  
Tags: , , , , , , , ,

The URI to TrackBack this entry is: https://aweeadventure.wordpress.com/2010/09/20/5-lessons-writers-can-learn-from-programmers/trackback/

RSS feed for comments on this post.

13 CommentsLeave a comment

  1. Great advice and great analogy. I especially like release early and iterate — your practical approach goes a long way toward dissolving some of the intensity that naturally arises when trying to develop craft and re-write a novel.

    • Glad you appreciated it Cathryn – I should point out that these five are only the tip of geeky approach to writing, I’ve project milestones, statistical tracking, checklists and all sorts going down!

      • I’m in Marketing for a high tech company — lots of parallels there as well. In fact, I have a spreadsheet for every novel, analysis of my progress (or lack thereof) etc.

  2. Having been a software programmer, I will heartily agree with what you’re saying.

    It also makes things easier to work with, because it cuts the problems into smaller, more manageable steps.

    • Ha – another programmer-turned-writer reveals themselves! I’m convinced that there’s something about the technical nature of being a programmer/developer/etc that demands a second source of creative output. Glad you liked the article!

  3. Good stuff! I have a suggestion for the look and feel of your blog, though. Make your paragraphs much shorter — no more than 4 or 5 lines — and use a sans serif font. It’s very hard to read as is.

    (I’m a writer, not a designer, but have much experience working with professional designers on corporate annual reports and web sites.)

    • Hi Jean – thanks for visiting the blog! You’re points about paragraph length are fair, its sadly the same with my fiction as well – I look back at the page and just see these terrifying tower-like paragraphs. I’m working on it. And the font type – yes that’s a good spot, hell I might even go and implement that this evening!

      • It’s such occurred to me that this is a prime example of the benefits of “Release early and iterate” – hurrah!

      • You know… I for one, disagree about Sanserif fonts. The old graphic designer saw is that sanserifs are easier to read. I personally don’t find them easier to read at all (nor harder for that matter) – but stylistically I prefer the appearance of a serif font. It just feels right to me.

      • You might have noticed I’ve now gone and switched over to sans-serif for the main text across the site. Like you I don’t find Serif fonts any harder to read but I have noticed that there is now a much better contrast between titles and content make the pages easier to scan.

  4. You’ve brightened up my afternoon sir! “Never test your own work” This one’s so very valuable. Another few sets of eyes is the best way to find the problems quickly.

    • Yeah that’s one that can’t really be stressed enough, although it can be frustrating what you get back. A recent discussion with my wife after she read some of my novel:

      “When’s this supposed to be set again? The 19th century?”
      “Yes – why?”
      “Did they have duvets in the 19th century, I don’t think they did.”
      “What?”
      “Duvets. You mentioned one. In the 19th century. They didn’t exist.”
      “It’s science-fiction I can do whatever the hell I want okay?!”
      “Well at least you spelt it correctly.”

  5. I did a minor in CS in my undergrad, so I have some appreciation for this one. I’m a very careful planner in my writing.

    I definitely need to follow the Backup dictum a little more carefully… particularly since I’ve been burned IRL because of it.


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

%d bloggers like this: