Develop – from Fandango’s One Word Challenge

Garry and I have had this particular conversation often. For him, writing is a developmental process. He has to “see” the entire post, or at the very least, he has to see the beginning and a hint of where it is going before he can start writing.

As far as I can tell, for blog writing anyway, I don’t develop anything. I get a little “bing” in my brain and I start writing. If, for some reason — like it’s the middle of the night or I’m cooking or something I really can’t stop — I try desperately to hang onto the tweak of an idea until I get my fingers on a keyboard.

When I was writing manuals for software and hardware, that was an entirely different story. I had to see in my mind the entire process, from the introduction to the final indices. While I didn’t use 3X5 cards (I never quite got “into” the whole card thing), I did write a preliminary table of contents — subject to massive changes when I got my hands on the product and realized the engineers had no idea how the product would be used.

I excused them for not knowing because while they understood what the software would do,  they had no interest in users.

I wanted to know how people would make it work and it was my job to help them do that. How they would interface with it. What graphics they would need. When they would want panels of information. When they need “instant” data — such as press “CTL D” for valid entries. And when they would need extensive background data.

It all depended on who was going to be using the product. Was it going to be a civilian who wasn’t entirely sure how the mouse worked? Or an engineer using this software to create new software for a new product. Two very different species of users.

Surely the engineer would not need an explanation of how to use a mouse or turn on the computer.

The hardest manual to develop was when the manual would be used by civilian and experienced people. Then you had to write for the least experienced user. Because someone who already knew the information could skip it and move on, but someone who was clueless would be grateful it was there.

A badly written manual — and these days they are all badly written because they are generated from developer’s notes and not actually “written” at all — can effectively confuse anyone. I remember one manual which used symbols — probably an early version of emojis — instead of text. Problem?

There were a lot of those tiny little symbols and if you didn’t have good closeup vision (anyone over 40 knows what I mean), it was amazingly hard to tell one from the other.

There were so many. You needed a glossary of symbols just to know what you were looking at. Mind you, this was a beautifully designed manual — written by (you guessed it) a designer. Her goal was to make it look great, so it was gorgeous. Useless, but pretty.

I didn’t get the job of writing it, but I got the call to come in and repair the disaster. I made a lot more money than I would have had I been given the job in the first place.

Probably, all of this explains why fiction is a big problem for me. Good fiction — even flash fiction — requires at least a minimal level of development. From beginning to conclusion, you need to see your way through the story to the end.

I write really good non-fiction. I write amazing instructions when I am trying. The rest of the time? I unwind ideas with a lot of diversions because that’s the way I talk. A story needs to roll out and much of its magic are the words themselves, the music they make. That kind of music doesn’t require structure or development. It is a feeling, a sense, a kind of magic, and beautiful words.

These days, in retirement, I don’t develop, plan, or structure. I write and what comes out is the whole of it.

Note: I do not have a single copy of any book I wrote in hard copy. I think I dumped them when I retired. I wish I’d saved one or two. But if I get desperate, I have a couple as documents, though I have a feeling they are in a format I can’t access anymore.