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