Help!

When do you know when you have crossed the line from a problem you can handle yourself to a problem you need assistance with?

This comes up often, or at least I hope it does, as we are all constantly bumping up against the limits of our comfort zones. Maybe the issue is with something you have read about, or remember hearing of in some blog or meeting, somewhere. But maybe it's something you just have no experience with at all. What do you do, then? No, I mean after the crying?

There is a deep and wide river of testosterone that runs through the middle of this. Two or three times in any given year, someone will tell me about the time they took a problem, threw it to the ground and beat it senseless, wrestling with it for seven hours before they finally figured out a solution. This is a point of pride for many people, but it always makes me shake my head. You blew a whole day on this? When you could have gotten an answer by calling or writing anyone in the Web Developer Network and ended up five or six hours ahead, productivity-wise? And you're proud of this?

But there is something to the Do It Yourself aspect. It's a great help in learning your craft. In a former life as a mainframe computer operator, I would encounter various situations where the computer would stop, issue some cryptic message and require some assurance or comforting before it would continue. The first week or so, it went like this: The computer would crash. I would call the Systems Analyst on duty, who would then guide me step-by-step to some resolution. But about a week into my new job, all of the Systems guys were away on vacation and I had to call their boss.

"Hi, it's Mark. The Cyber crashed again" I told a frustrated manager. "What does the error message say?" he replied. I dutifully read it off, over the phone. Now, understand that these big machines don't just stop and throw up a little box on the screen with an "Okay" and "Reset" button. You would get error messages that themselves were clues as to what kind of problem you were having. Every conceivable error was cataloged and cross-referenced in huge manuals kept in a cart near the main console. CO411 might be a core, or memory problem—the programmer was asking a program to think about more than he had given it room to comfortably work in. Or it might be IO234, a problem with the Input/Output area of the big machine. Some trouble with a tape drive or a printer. Before, when I would call, the programmer would walk me through fixing the problem and I would move on, thinking my involvement was done. I was just a clerk, running a big machine.

But with their boss taught me how to learn about the machine, and what it was expecting. He wanted to teach me how to learn (what he really wanted was to get back to watching M*A*S*H on TV), so I would be less likely to call back. Soon enough, I was calling analysts with one of the giant manuals opened in my lap, my finger already on the reference for the error message I'd gotten. I would suggest a way to fix things and they would approve it and we'd move on. Within a few weeks, I wasn't calling people and interrupting their evenings, I was sending them e-mails explaining what had gone wrong and how I had fixed things. That's about the time they started bringing in pizza for me, in the evenings.

Many things in life seem to work in three's and this is where I draw the line, myself. If I discover a problem I will try three ways to fix it myself but at that point it's probably easier, cheaper and faster to call in an expert opinion. This has served me well in technology and even working on things around the house. I'll fiddle with it, I'll monkey with it and then I'll futz with it. But if it's not fixed after my fiddling, monkeying and futzing, then damnit, it's time to call a plumber.

Know what you know, and learn what you don't. And don't be afraid to ask for help.