Debugging The Manuscript
- Character Questionnaire
- An Introduction to E-Cigarettes
- Why I Hate DRM
- On Being Stuck
- Writing and Roleplay
- Murphy's Law
- Apocryphal Tales
- Are mobile phone masts bad for health?
- Rebuilding the Garden Pond
- About Me
- Pictures Of Cats
- Cosmology for the Layman
- Magnatune Demo
- Ambercon UK
~ o ~
For an open-source, world-class network protocol analyser.
Diceless role-playing in four-star luxury.
~ o ~
As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.
— Maurice Wilkes
Not many people understand programming these days. The Internet and the XBox have created a generation for whom computers are consumer boxes. Back in the 1980's it wasn't like that. To get a computer game running you had to type it in, or if you were rich enough to afford commercial games, at least know the right commands to load it from cassette tape. All the kids knew enough to be able to wander into a Tandy store, type a two line program:
10 PRINT "TRS80 SUCKS!" 20 GOTO 10
They would set it going and then run away laughing.
The glamorous art of programming, the art schools used to teach, and may soon teach again, is the art of putting a program together. First you design how it is going to work. You decide what its initial conditions will be, and what its output will be, and how it will get from one to the other. That's very boring and everyone tries to skip that bit. Then you write loads and loads of cryptic instructions to tell the computer to do what you want. That's the fun bit. That's the bit you see in the Hollywood movies. The sort of program that you write in school might be a dozen lines of code. The first time you try to run that program it will probably fail, so you find the silly mistake, and you correct it, and the program works.
And then you get a job as a programmer in the real world.
Commercial programs are measured in thousands of lines of code and not just one or two thousands, maybe hundreds of thousands of lines. Windows XP had forty five million lines of code. That's a lot of opportunity for making mistakes. Some of those mistakes will be trivial, like the one in the programs you wrote in school, but some of them will be so complex that they take days to fix. As a rule of thumb, programming in the real world is about one third programming and two thirds debugging, if you are lucky. That one third also includes the design work you do before you set finger to keyboard. So the actual writing of code might be only one sixth of the time you spend getting your program to work.
Nobody ever tells you that the majority of your work is going to be finding and fixing problems.
Then you give your program to the test department, and they find more problems for you to fix. Finally they accept it and it goes off to the marketing department who spend ages working their arcane magic until it is finally released to the public. Then the reviews and the support issues start coming in, and you find there are more problems that both you and the test department missed.
In school, when you wrote an essay or a story, you did it in one go from start to finish. When you wrote that final full stop, you were done. Maybe the teacher pointed out your spelling mistakes and bad grammar, but those were silly mistakes and easily fixed.
And then you get a job as a writer in the real world.
What nobody ever told you, is that the first draft is only the first step of the journey. You will be going over that manuscript again and again, finding things that don't work and correcting them. It isn't a quick process either; it will be the majority of the time you spend working on the story. You go through draft after draft until it is as good as you can make it. Then you send it to the publisher and back comes a list of more edits for you to make.
I could force the analogy further, but the problems in writing are not really the same as bugs in programs. Maybe forgetting to mention a detail of background that makes a plot point confusing might correspond to an uninitialised variable, but that's rather a stretch. Other editing tasks such as polishing the prose until it shines, engaging all the senses, or making sure the first paragraph grabs the reader, have no ready analogues in programming. But like debugging, editing is a skill that has to be learned, and it is almost entirely separate from the skills you learned in school. There are books that help you learn how to write, my favourites are the Elements of Fiction Writing series from Writer's Digest Books1, and they tell you what your final manuscript should look like. Between the lines, you will eventually gather that editing does play a part in writing and that your first draft will not be your final one. The full truth sinks in later when you start to put all this into practice and start submitting work. Like a commercial program, it has to be smooth and perfect with no rough edges, and that takes a lot of work; more work than you ever imagined when you were writing two page stories in school, and probably more than you feared when you decided it was time to write your first novel.