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!
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):