As I’ve been continually switching between working on the final draft of a paper (submitted) and the final version of my candidacy document (just needs to be sent to committee members) and my coding project, I’ve started to notice a lot of similarities. And I’ve also noticed that my writing could benefit from the way I approach coding.
What do I mean? Well a few things, specifically how I “edit” code versus edit writing. So, after thinking about it a bit, here are four editing techniques that I have no problem using when coding, that I (or maybe you) could benefit from using on my writing.
- If it doesn’t work, throw it out. Just because you’ve spent time on it, doesn’t mean it’s good. And it’s not always worth saving. Sometimes, the smartest move is to just start over. However, I rarely throw out code by permanently deleting it, instead I just comment it out. Then, should there turn out to be something worthwhile later, I still have it around. If you write using latex, it’s possible to do the same thing with your writing.
- If the structure/organization/flow isn’t right, change it. A lot of the times when I’m writing, I work on the outline first, especially if it’s going to be a longish document (more than a few pages). I find this process is good, because it helps me organize my thoughts, and what I want to talk about. However, I often become stuck to that original outline, and find it difficult to take that step back and say this would be so much better, if I just swapped around these few sections. However with programming, as you add in features, or your requirements change, you often end up doing this just because it’s going to make your final program cleaner, easier to follow, and easier to code. All of those are goals you want with writing, so why wouldn’t you do the same there?
- Why re-invent the wheel? If it’s been done, re-use. Of course, I’m not talking about plagiarizing here. But, a lot of coding is done by building on what others have already done before you. You may use libraries of code or find an implementation of an algorithm. Of course, you should remember where you got the code from, the same way you would cite who you got the quote from. I’m also not saying that I don’t cite and quote other’s work, but I find we like to cite only a sentence or, preferably, less. But if someone has a great example, use theirs and give them the credit, even if it’s going to take a few lines to explain. That’s what block quotes are for.
- The first version should never be your final version. When I code, I’m constantly making changes to my document and going through multiple versions until I get the actual behaviour and outcomes that I’m looking for. I don’t think I’ve ever managed to write an entire program right the first time (and I’m not counting the few lines of code you’d do for early programming assignments). However, when it comes to writing, it’s so easy to say I wrote my paper, I’ve read it over (and “edited” it) and now I’m done. Learning how to constantly work at, tweak, refine, fix, whatever you want to call it, your paper is a valuable skill – and your paper will be much better for it.
I’m sure there are more areas where you could draw a parallel between writing and coding. Have doing either one of those taught you something about the other?