It’s not entirely analogous, but there are ways in which programming is like writing fiction. Maybe it’s because I do both, and my lessons from one activity inform how I perform the other. Nonetheless, even if the connections are forced by my perspective, they are able to be connected. So here’s where I see them being similar, or at least having common usable approaches.
It’s easier if you have a plan. It doesn’t have to be exceptionally detailed, and it doesn’t have to be set in stone, but whether writing a program or a story it helps to have an idea of what the end result should be. I know that some folks like to just start writing and see where it takes them, and that’s fine. Whatever works for you is the way you should do it, right? Me, I find it a lot easier to put words down if I know what tone I’m going for and have some loose structure in mind.
You’d think that knowing what you’re trying to accomplish would be a given for programming. After all, there’s a requirements document and everything! Well, for most of my career I’ve been on agile projects, and very few of them had a requirements doc. Far too many, in fact, had us start writing code before we even knew what the project was about. There was one project at HoneyPot where we spent $1 million on development before the client had agreed on requirements. That went over poorly.
Entire sections may need to be rewritten. This is a hard lesson for writers, but it’s widely understood. What seemed like a great passage when written might need to go because of pacing considerations. Or a part of the plot wasn’t working, and you needed to rework the scene to support a revision. It’s all part of the process.
For many programmers with whom I’ve worked, touching code a second time amounts to failure. The ingrained model is “One and Done” — a sort of measure twice and cut once approach to coding. This of course assumes you have full and correct requirements, which you won’t. Ever. It’s simply unrealistic to believe that new requirements won’t lead to a rewrite of part of the code base. Nonetheless, I’ve seen a developer literally on the edge of tears because yesterday’s code didn’t support today’s business needs.
It’ll never be perfect. I spent 10 years rewriting the first three chapters of a novel. Those three chapters were pretty great! In that time Stephen King pumped out enough books to fill a shelf. Big, thick, hippo-choking books. Done is better than — well, not done. There’s a point called “good enough”, and it’s probably lower than you think. Just read a best-seller; you don’t even need complete sentences anymore.
I mentioned that programmers don’t like to revisit code. One tactic they use to avoid it is to make their code as perfect as they can imagine, able to take on everything they can think of. But you can’t think of everything, and there’s a point beyond which you’re spending time solving a minor problem when major work needs doing. Do a good job, but let it go.
Lastly, and most importantly, whatever gets the job done is right!