geardrops [blog]

As I’ve mentioned in the past, I’m currently working towards my master’s degree in computer engineering. This is among other things which consume my time, such as the working, the boy, the writing, the baking, the video games, the fire stuff, the pretending I’m normal so my family doesn’t cut me from the will. I am spinning many plates on sticks. Good thing most of it is Corningware.

Algorithms has taught me many debatably useful things. Such as:

– patience (I will not walk out of this class to get ice cream, yes it is boring and ice cream is delicious but I must not fail this course)

– restraint (don’t throw pens at the back of that one guy’s head despite how irritating he is, despite how useless his blurted-out and incorrect responses are, despite how obnoxiously nasal his voice is, seriously guy, can you talk through your mouth, or is it just a sound-shaping peripheral?)

– and which foods not to eat in closed spaces (cafeteria chili)

But in thinking about it, many things I learned in algorithms apply to writing, so I’ve decided to list them. Don’t worry if you’re not technical, everything is explained.

Fun aside: Writing really shares many parallels with coding. For instance, style. There are some writers whose styles are so distinct that you can be handed an unlabeled page of fiction and name the author. There are programmers on my team at work whose programming styles are so unique, I can instantly pick out who wrote what.

(1) “Brute Force will be your first answer. It should not be your only answer.”

You will find a Solution to a problem. And it will be quite good and efficient, in your eyes. This will be your first Solution. But then you look further and say, well, perhaps a vector was not my best choice. And oh, look, I can actually run these two operations simultaneously. And wouldn’t it be better if I could spawn this off as a separate process and let the rest of the app continue working. Et cetera. This will be your first Solution. It better not be your only solution.

You will compose a Story. And it will be quite good and lovely, in your eyes. (Or perhaps not, depending on your particular mental configuration.) This will be your first solution to the problem of writing down your Story. But even though you really wanted a specific character to play a specific role in the ending, maybe it’s not his job. Maybe it’s her job. Maybe it’s their job together. Maybe you have to cut him entirely from the story. This is your first solution. It better not be your only. No matter how lovely you think it is, it can be more lovely.

(2) “The problem will be NP-Hard, but not too hard.”

There is a vast, gaping difference between describing a problem and solving it. Certain problems are very easy to describe. For example, the Travelling Salesman problem. You have a salesman. He is, as the name denotes, travelling. He has to fly to a bunch of cities the area he’s covering, and each city is connected by a flight, and each flight has a cost. What is the cheapest way to fly to every city, stopping at each city only once?

Sounds easy, non? If you find the solution, please let me know. I’d love to get in on that sweet multi-million-dollar action. (No, seriously. There’s heavy money on the line if you solve that in under O(n²) time.)

This is not unlike a good book. The IDEA is easy (”It’s AS I LAY DYING as a comedy set in space!”). But writing? Well that’s where the work really comes in. And the right execution will make or break it.

(3) “One problem can have infinite solutions.”

There’s the oft-said adage that there are only ten sitcom plots, and somehow these manage to get recycled into twenty seasons of the Simpsons, eleven seasons of Married With Children, and far too many seasons of Friends, seriously people, it took far too long to stop paying them. And though we’ve figured this out, it still seems fresh to viewers.

This is because while there are ten plots, or “problems” to solve, there are infinite variations on the parameters entering, and on the specific ways you can treat them to still come to the same conclusion. And if there wasn’t, we’d all have the ancient Greek plays memorized by now.

(4) “Divide and conquer.”

One of the methods of attacking a problem is to divide it into smaller, related problems. For instance, say you want to sort a list of names. One method might be to pick a random name in the list and sort the list so if the name comes before your picked name, you put it before your picked name, and if it goes after, sort it after. Then sort each remaining chunk in the same way, on and on and on, until you have a sorted list. (AKA quicksort)

Treat your novel like this. Writing a novel is a big problem. Having a huge plot is a difficult thing. So break it down into smaller bits. Your main character has to get the MacGuffin at the end and destroy it. Divide it into sub-problems: How does he find out about the MacGuffin? Who’s hiding it? How must he destroy it? Is he going to hurt anyone in the process? Divide each of those into smaller problems.

It seems like a lot, but if you tackle them one by one, you’ll have a story at the end.

(5) “Sometimes, brute force is the answer.”

You can have a lot of tricks to help you get through a problem, fun things to try, paths to go down. But at the end of the day, sometimes you have to set your ass down and just write, even though it isn’t working, even though you hate what’s on the page.

Because writers write, especially when it’s hard.

Tags: algorithms, Writing   Posted Computers, Nerd Things, Writing |