The cure for bloggers block

I realize now that I need a plan of attack for successful blogging. It's difficult to get the "juices" flowing on demand. I image this is a small scale of what real writers experience. I've got to get into the mooood and I've got to figure out exactly how to do it fast in order to reach my blogging goal.

First, I have to make coffee.
Next, I have to be free of distractions and something significant will have to have happened within the last few minutes to have a topic. More realistically, I think I'm going to have to use the small notepad that I already carry around in my purse for ideas. This can eliminate the guess work of topics. It has not been used for that purpose yet. E used it to entertainment herself at a pizza shop once. So Since I do not have a list yet then I'm going to have to squeeze one out.
I'm also discovering that writing requires the same train of thought that computer programming requires. Its actually a lot like computer programming.

Let me explain.

When I first sit down I've got nothing. A complete blank. Then after a minute or so of reading the surrounding code or previous blogs the brain gets in gear. I start typing words similar to .NET variables that I know I will use later so I'll go ahead and initialize them now. Then I'll begin to see a clear path where sentences are flowing and I will have to make a decision of whether this is good enough for a start or if I need to take an alternate path so I'll have to trust my instincts. I may hit a brief road block but I can cut that sentence/piece of code out and move it around until it makes sense. Ahhhhh, now that I have a substantial block of logic, er, text, I'll do a quick proof read. Programming requires frequent...

OK, this is a great example of how detrimental interruptions are. E just asked me to see her princess she made on an IPHONE app and I'm having trouble getting back into the groove. B has just walked over to ask me what I'm doing and is literally standing over my shoulder reading this blog.

...Back to my comparison (while I attempt to block out the B and E conversion behind me), I was starting to describe the debugging process. Proof reading is the debug of writing. I have to read and re-read every line/sentence and dig into them to determine what it can be interpreted as. Then, I will tweak here and there until all the initial bugs are out and the work flows smoothly. As with any piece of code, there WILL be bugs. My writing will NOT be pristine because my mind easily over looks syntax, er, diction since I already know what the text should read. I'll go back and edit as needed but for the most part, I am satisfied and then publish.