Troubleshooting Professional Magazine
Natural Born Troubleshooters
[ Troubleshooters.Com | Back Issues ]
|"Troubleshooting ability is something you're born with. It can't be taught or learned."|
The speaker usually has unflappable faith in the statement. Having never received formal Troubleshooting training, he believes his "Troubleshooting ability" is an inborn trait. I don't argue, even though I have first hand knowledge it's a false statement. But in this issue of Troubleshooting Professional I'll show you the irrefutable evidence I was shown, and show you how to teach yourself to be a "better Troubleshooter", regardless of how "good" you already are. So kick back and relax as you read this issue. And remember, if you're a Troubleshooter or Open Source advocate, this is your magazine. Enjoy!
In fact, this was just the latest in a long, continuous slide down the ladder of success. After an unremarkable college stint culminating in a BSEE, he'd taken a job as a corrosion engineer. Overworked, underpaid and vastly underrespected, he'd taken a salary cut to become an electronic technician at a nationally recognized university. That's when the real trouble began.
His job was to repair electronic equipment, and he couldn't do his job. He could draw a high or low frequency model of a transistor, design you an amplifier or flip-flop, or use boolean algebra to reduce a complex problem to a few gates. But he couldn't fix electronic equipment. Word got out. Some coworkers took pity, some issued warnings, and some were cruel. In response to a question concerning how to best fix a reel to reel tape recorder, a professor told him, with several others looking on, to pry up the front panel and drop a lot of oil in the machine. The loser had believed it, eliciting chuckles from the professor and several bystanders. It wasn't much different than teasing the cripple or the retarded person.
After six long months of non-performance, he was fired. He drifted between menial jobs for a couple months, and then was hired as an audio technician by Pacific Stereo. Every month Pacific came out with the Technician Production Report, a list of all technicians and their production, sorted by production. Since there were about 40 technicians, in a very real sense it was a "top 40". His first three months he was two or three from the bottom, thereafter moving up one or two places. Because Pacific paid on commission, his paycheck was half that of the engineers he'd graduated with. A total failure, he applied for a janitor job. At least maybe he could be successful at that...
His potential janitor job had fallen through in March, so he stayed at Pacific. Soon after, he discovered a method of repairing stereo equipment. He kept splitting the stereo in half, continually boxing the problem into a smaller area. His cousin said that made a lot of sense, because in computer programming the quickest search is a binary search.
Using his new stereo repair method, he made the upper half of the Technician Production Report in April. He was #15 in May, #8 in June, #6 in July, and #4 in August, and #2 in December. As one coworker succinctly put it, "word is out that you can fix hi-fi".
As if things weren't intriguing enough, he had made an interesting discovery while fixing his television. He had never received a minute of training on the repair or operation of televisions, yet he fixed the television. He used his stereo repair technique to repeatedly cut the remaining problem area in half, using a block diagram of a Sams Photofact book to decide how to divide. It dawned on him that given his stereo repair technique and a block diagram of a given machine, he could troubleshoot anything. Realizing that the technique and the block diagram were tools, he named the technique "Divide and Conquer", and the diagram "The Mental Model".
So if you tell me Troubleshooting can't be learned or taught, you're telling the wrong guy. I've been the worst, and I've been the best, and the only difference is what I learned about Troubleshooting Process.
Certainly hard core drug addicts can't troubleshoot. Nor can severely retarded people not trainable for anything beyond handling a broom, or severely psychotic people not helped by medication. Kids under 9 years old would also be poor prospects. Arithmetic, simple one variable algebra, and a basic understanding of cause and effect are necessary for Troubleshooting. I would guess that a fairly bright nine year old could be taught the Universal Troubleshooting Process and the basic block diagram of a computer, after which he or she could repair computers. Before the age of 9 I think that would be a pipe dream.
Now that you can get luggage with wheels, it seems pretty silly to carry it, doesn't it. About as silly as mental simulation Troubleshooting.
You've seen mental simulation Troubleshooting. Starting with an immense collection of facts concerning the system under repair, the guy repeatedly imagines a cause and works forward to see if it matches the symptom. Or maybe takes the symptom and works backward to deduce the cause. The ultimate macho Troubleshooting, like sprinting the length of O'Hare carrying a couple hundred pound suitcases. Many try, but few (only those a standard deviation east of genius) can pull it off. The prevalence of mental simulation Troubleshooting explains a few phenomena:
My secret is the simple mathmatical concept of geometric growth (or in this case, shrinkage). Sixteen tests reduce a potential root cause to one in 65535 components. Can you imagine what kind of intelligence it would take to juggle those 65535 components in your mind? To learn about every one of those 65535 components? Can you imagine how your head would feel at the end of the day? Just say no to mental simulation Troubleshooting!
Increasingly, the world belongs to the empirical. The accelerated learning techniques I've documented in "Rapid Learning: Secret Weapon of the Successful Technologist" depend heavily on experimentation. Experimentation is how tiny children learn so fast, and it's how egghead scientists push the boundaries of human knowledge. For every Einstein having an inspiration and shouting E=MC2, there are thousands of scientists carefully using the scientific method to explore where no one has gone before.
Every Troubleshooting Process makes extensive use of experimentation. Use a Troubleshooting Process. Save your genius and inspiration for less mundane tasks. Let Troubleshooting Process be your wheels, and arrive at your real work refreshed.
I have a saying: "There's no bad technology, just bad documentation.". Now obviously this saying is true only of stable, consistently performing, modular technology. Windows is bad technology. But look at the vi editor. It's almost impossible to fathom without a book. Navigating the help files requires a knowledge of vi commands. How's that for a buried shovel? The vi man page is scant. The vi editor has a reputation as a real pig.
It's not. There's no bad technology, just bad documentation. In fact, vi is an incredibly powerful, speedy and productive editor. It's my main editor, in Linux and Windows. Heavy duty macros, syntax highlighting, regular expression search and replace, character, line, and columnar cut and paste, undo (infinite in many implementations), and best of all, everything accessible from the touch typists home position. vi got its reputation because of inadequate documentation. As the old saying goes, "if you're not part of the solution, you're part of the problem", so I'm writing "Rapid Learning vi". I expect it out soon after the release of "Samba Unleashed". If there's one thing I know how to do, it's make the complex simple.
But I digress. Documentation is only the symptom. The root cause is elitism. Anti-empiricism. It's a philosophy that if the reader needs to see examples or experiment in order to learn the product, they don't deserve to work with your operating system. Banish them to the Redmond penal colony. If they can't do page layout in a teletype interface, they're just not intelligent enough for a real OS.
If we want Linux to survive, we need to welcome newbies with open arms.
We need to recognize the fact that many of them are not as intelligent
as the yggdrasil pioneers. But properly respected and mentored, today's
newbies are tomorrows Linux ambassadors, bringing it into the enterprise.
Proper respect starts at the LUG and in neighborly conversation. Windows
is bad, not people who use Windows.
Linux is very different from UNIX. One's GNU GPL, and one's proprietary that sold for five figures in its heyday. One's an OS for the common man, and the other was for the wizards fortunate enough to get their foot in the door. One is mentored worldwide all over the net, and the other almost a secret society. There are two commonalities -- they both work extremely well, and, unfortunately, they both have a history of elitism. That must change, because we're no longer egghead revolutionaries. Now we're ambassadors.
By submitting content, you give Troubleshooters.Com the non-exclusive, perpetual right to publish it on Troubleshooters.Com or any A3B3 website. Other than that, you retain the copyright and sole right to sell or give it away elsewhere. Troubleshooters.Com will acknowledge you as the author and, if you request, will display your copyright notice and/or a "reprinted by permission of author" notice. Obviously, you must be the copyright holder and must be legally able to grant us this perpetual right. We do not currently pay for articles.
Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.
Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):