Not too long ago, I found myself struggling I was writing the Tech Speak column for the current issue of STQE. (More accurately, I was slogging through a string of first drafts that left me unexcited, uninvolved, and frustrated.) Eventually, I asked for help, and my friend, Bob King, advised me to write about being stuck not knowing what to write about. So I wrote about being stuck and the strategies I use to become unstuck, and ended up with a column I really rather liked. (I’ll post the STQE column on my website in a week or so.)

Since then I’ve been paying attention to STUCKNESS. Are there any patterns in the ways I become stuck? What other things do I do to unstick?

Here’s one bit of stuckness I noticed:

Like many of us in the software business, I am quite dependent on my computer. If something happens to my computer and I loose my data, I’m toast.

I looked around at automated backup options, and queried my computer-savvy pals about how they were backing up their machines. I went out and bought the backup program they recommended.

I diligently read the product overview and install instructions. The software installed correctly. I was ready to go.

I set the back up parameters, formatted a CD and pushed the start button. The program went into action. Everything looked like it was working just fine, until I got a little notice that backup media was not available.

I opened the CD drive, and sure enough, there was a CD there. I tested the CD drive and the CD with another program and it worked fine. I checked for new drivers, and found I had the latest version. I tired a different CD–same result.

I went to the support site for the software package. I spent a great deal of time combing through the knowledge base. As nearly as I could determine from the support site, I had a hardware problem. So I went to the support site for my computer manufacturer. I spent some more time there. Eventually, I determined that the software wasn’t recognizing my driver. I needed either: a) a different driver, or b) a different device.

I don’t know much about drivers. I sure didn’t know enough to determine which one was going to work better than the one I had, and if I changed it, what else would break.

So I put off dealing with it. And then I put it off some more. I am embarrassed to tell you how long I put if off.

I was stuck because I didn’t know how to solve the problem in front of me. I decided to buy a new device.

I went to the computer store and got to chatting with the sales dude. He asked why I was looking to buy a tape back up. I told him my story.

“Oh!” he said. “You don’t need a tape drive. You need to pitch that software. No one but a techie can get that to work. Here buy this.” And he handed me a box. (Of course, I was a little crushed to be relegated to “non-techie” status, but, in truth, it has been –ahem — several years since I’ve written code.)

I drove back to my office, installed the software and backed up my data. Took about 20 minutes.

So here’s the part about being stuck: I think not knowing how is a fairly common cause of being stuck. When I’m stuck because I don’t know how, I need to ask for help, either from a person or by accessing information resources (like support sites, instructions, or a manual).

In this little story, though, I had another layer of stuckness: I became focused trying to solve an intermediate problem (the backup software not recognizing the CD drive) and lost sight of the real problem.

Now when I notice I’m stuck, I can ask myself:

Am I framing the problem correctly?

Is there another way to solve the real problem besides going over this particular obstacle?

Hmmmm. Ever seen this happen on a software project?