DEV Community

[Comment from a deleted post]
Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

I've been writing fiction at a professional level for over 15 years, and programming for over 8. Here's some feedback on both angles, so pardon the long comment. :)

There are actually two major approaches to fiction writing, and both work well, but even that's a simplification. Every author forms a specific combination and pattern that works for them. For me, each story demands a slightly different approach.

That caveat stated, you can essentially separate authors into two major categories. Plotters will sit down and write out every detail of their plot and story before writing. Seat of the Pants writers just start writing, and revise as they go.

Stories can have multiple major characters, and each requires a different sort of attention. For many major ones, we'll write out a character profile. Sometimes, the character just walks in, and we write out what they say and do, working out their personality as we go.

Contrary to what one might think, we actually pour a lot of effort into our secondary characters, almost as much as our primaries. (The only reason to put in extra effort into crafting a character is if we are using their Point of View [POV] in the story.)

Stories also don't necessarily form linearly. We don't all start at chapter 1, then write 2, then 3, then 4, and so on. We'll write scenes as we think of them, string them together, and revise individual pieces as we go. I have two current manuscripts with multiple mid-book gaps, and several finished books with that followed that same pattern.

Some of us write sparsely, only putting in what is necessary to make the story go, and then add details later. Others pack as much detail as possible in, and then trim later.

Some of us, like me, edit as we go. My first drafts look like most people's third or fourth drafts, and professional editors are often hard pressed to find much. Others write "rough" and revise the finished manuscript.

In all of these areas, and more, there isn't a wrong way. One must only be able to craft a solid, finished book at the end of the process. What works for me won't work for another author, and visa-versa.

I will confirm, however, that all successful authors are readers in some capacity or another. What styles and genres they read depends on their interests, but we all read. Even so, we have to be careful about what we read! Most of our reading will be in our genre and style. Writing styles change as quickly as fashions do, and an author who writes like Charles Dickens is not likely to be published today (unless, that was the point...which for one of my published stories, it was.)

You are also correct about accepting criticism. Authors invariably have a host of others read their work. We have critique groups with other authors, we compel friends and family to read our manuscripts, we read them ourselves out loud (we're often our own worst critics), and we have one or more professional editors make multiple passes over the manuscript. A finished book will often have been revised dozens, if not hundreds of times. One of my fantasy novels was started in 2007, "completed" in 2010, and has been revised mercilessly more times than I can count since, even this year. (I'm waiting on release until the entire trilogy is done.)

Coding does indeed follow a similar pattern. It isn't coincidence that many great coders are also great authors. Here's a few thoughts on those four points:

  1. Reading other code is very important, but be careful which ones you read. As I said, authors read work in their style and genre, because we pick up the style patterns and incorporate them into our own work. Romantic comedy authors won't usually immerse themselves in thrillers, and thriller authors won't usually immerse themselves in romantic comedies. We tend to read what we write.

  2. It is wise to solve one problem at a time, but you must also remember that problems tend to connect themselves. In writing, I might decide to add a conflict between two characters, only to realize that one needs a past for that to work, and I have to write that in first. That means that the character's entrance needs to be reworked, and how he handled another conflict was wrong...

In coding, I might want to add time bonuses to my game's scoring system, when I realize that the timer system has to track time between answers first, as well as tracking the entire game time. This requires a rewrite of the timer system, which also requires me to rethink how the game handles threads.

I find it useful to always write down my goal, and then write down each thing that has to happen first.

  1. You obviously need to write, and definitely need to test, but the timing of those tests varies. When I was writing Omission, I couldn't begin testing the game for six hours, because I needed several pieces in place before the program would even be executable. That's because I write bottom-up - I layout the framework first, stub in functions I don't need, and start adding the critical behaviors. Once the whole basic framework is humming, I can start adding things.

This is just like how each author follows a different pattern. You have planner coders, and seat-of-the-pants coders, and both patterns work when refined, practiced, and used responsibly.

Refactoring and optimization is like editing in writing. While you cannot begin to edit a scene you haven't written, some authors like to make initial revisions as they write, so they have a clean manuscript to go back to. That's the way I work in both writing and coding; I will write the code, clean it up as soon as I spot a place where it could be quickly refined, and move on. This may mean swapping to a more effective algorithm (since I'm already there), or splitting a class in two to make the code more maintainable as it grows. I have to do it this way, or I forget and have crufty code. This doesn't mean that's the only way to code, but it works for me.

Yet, I agree with Knuth's "premature optimization is the root of all evil." You have to know when to quit! While I might make major, obvious revisions as I write, I don't start fine-tuning either book scenes or codes until I go back over for revision.

Definitely read and delete! The author who is in love with his own words, and the coder who is in love with her own code, can never grow.

And, yes, just as authors cannot edit their own work, coders cannot properly code review themselves alone. We should always review our work, but we must ask others to do it, and the more the better! Don't just look for more experienced authors or coders, look for anyone who can give reasonable feedback! I've received valuable input from writers and coders with much less experience than me. I also look for readers or users to give me feedback on the finished product.

Incidentally, if you ever want a proofread on your articles, hit me up. ;)