I have been working in technology for more than twenty-five years. I have repaired computers, NSA crypto machines, and sophisticated, peripheral communications equipment. At first I was like my peers, well trained and possessed of high intelligence. I had been a data communications professional for nearly three years when I got the best advice I ever received.
I was working late one night, when the shift supervisor appeared. I had been unsuccessful for more than two watch sections in trying to fix a crypto unit. Crypto units are just highly specialized computers. The watch supervisor was my friend Dwaine. He asked me “Haven’t you fixed that machine yet?” I admitted I was having some problems, but I hoped to be finished soon. Unfortunately, I had no clue as to the solution to my problem.
Dwaine suggested he could help, and I replied with some disdain that he was not qualified on this specific crypto machine. He scoffed at me and said supportively, “Just bear with me one time, will you?” First, he asked me if the symptoms had changed since I began the troubleshooting process. I responded, “No.” I realized Dwaine was checking to see if another problem had occurred which was masking my search for the initial problem. Repairmen only learn this trick occurring through experience.
We opened up the system schematics and Dwaine asked me which circuits would be most likely to cause the symptoms I was currently seeing. Step by step, we worked our way through the schematics, with Dwaine making me use my expertise to follow a strict but logical procedure. In fewer than twenty minutes the crypto was fixed! I never forgot the unspoken lesson.
We all have tunnel vision which may prevent us from performing at our best. Perhaps we are just too tired. I prefer to believe, in this case, that I was too flexible in my troubleshooting and was satisfied I was doing my best – when, in fact, I really was not. Or perhaps I was mentally lazy and too sure of myself, too overconfident. At any rate I learned a valuable lesson – the best advice I ever received.
Several years passed, and I was a doctoral graduate student in Psychology. In the Math building next door to mine, my friend Dan’s office light was on at 3AM one morning. Dan has been my friend for more than twenty years, and he is the most brilliant IT professional I have ever met. I went over to see what was happening. Dan had been struggling for the previous eight hours on a computer assembly language program. Ordinarily, Dan was a brilliant programmer. I offered to help, and he responded in much the same way I had responded to Dwaine years earlier. “You don’t know anything at all about this CPU chip,” he said. I said, “I know it uses RPN logic (Reverse Polish Notation), but I’m not tired, and you are.” Dan sighed in compliance and walked me through the steps of his program, and I asked intelligent questions about what might go wrong at different points in the process. It was only ten minutes after we started that he realized his mistake. He was very surprised and grateful, and I had a new troubleshooting tool – and the best technical advice I ever gave.
This past semester I had another opportunity to expand upon my advice paradigm. A student in my Unix class asked me for help with a problem at work which had begun two months before (February). He is a Unix system administrator for a sales company.
Each night the company computer literally came to a halt at 11PM and became sluggish until the day shift came in to reboot. He was clueless as to the cause. I asked him what diagnostic programs he was using. He replied, “Top.” I showed surprise because the ‘top’ command has never offered me anything useful. I suggested he needed to use the ‘ps -ef’ command to determine what processes were occupying the computer’s time at 11PM. In fewer than five minuteswith a remote connection from the classroom he found the problem and understood it. He had to fix it later, however. It seems that each time a sale was made an e-mail was sent to the buyer with an order number and a copy of the invoice. For some reason (unknown at the time) the problem began when the computer inexplicably began to send out hundreds of thousands of e-mails each night – a kind of internal Denial of Service problem.
So, this last problem completed my problem solving paradigm. Try to get a fresh look at the problem, and if you are still clueless, seek the advice of a more experienced subject matter expert. Is this over simplification? Perhaps, but I see the same hurdles in a faulty problem solving process over and over, and it really helps if you have many professional contacts who are quite knowledgeable about areas in IT in which you are not.
I hope this helps you.
