Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 4 Issue 2, February 2000
Natural Born Troubleshooters
Copyright (C) 2000 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

[ Troubleshooters.Com | Back Issues ]

CONTENTS

Editors Desk

By Steve Litt
It usually comes right after "troubleshooting what?". It's spoken by Troubleshooters and  technologists I highly respect. I've learned not to argue. It goes something like this:
"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!

Steve Litt can be reached at Steve Litt's email address.

Natural Born Troubleshooting Failures

By Steve Litt
Once I convince someone I can teach Troubleshooting, they next mention that some people are just hopeless. Never mind that we've all met subnormal IQ people who could make that old Dodge Dart leave 100 feet of rubber, or fix word processing macros that write data in an access database. Nope, they say, some people just can't Troubleshoot. It depends what they mean by "some".

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.

Flat Earth types

There are certain people who refuse to listen to any rational assignment of cause to effect. You'll most likely find them on Venice Beach offering crystals to every person with a backache, whether the backache is caused by stress or a landmine. Or maybe basing their life decisions on the words of an astrologer. The 8/1997 Troubleshooting Professional, whose theme is "Troubleshooting, Luck and Superstition", extensively discusses this type of person. Their mind is made up, and little can be done for them. They can't troubleshoot because they don't recognize cause and effect. If you have children, teach them cause and effect *very* early to prevent this.

Everyone Else

That leaves everyone else. The vast majority can become ninja Troubleshooters once they're taught the Universal Troubleshooting Process and the Mental Model of a machine or system. Eddy Belew, an Era 4 Troubleshooting Process ninja, sums it up best with his favorite phrase: "It's not rocket science."
Steve Litt can be reached at Steve Litt's email address.

The New Empiricism

By Steve Litt
Have you seen these guys with wheeled luggage? What sissies! A real man can run two terminal lengths lugging a 50 pound suitcase in each stovepipe arm. The morale of the story is clear. If you wanna be a real man, use wheelless luggage. If you want to arrive with your suit still pressed and your shirt still dry, by all means use wheels on your luggage.

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:

In half the time it takes a guy with a brain the size of Texas to solve a problem using mental simulation techniques, I can (and regularly do) solve it empirically (experimentally). While the Einstein understudy busies himself calculating why the Samba printer doesn't print, I print from the command line, create a smb.conf print command parameter to log requests, examine the path directory, narrow it down to the root cause, fix it, and move on to the next problem. I've gotten a reputation as a genius by outperforming geniuses. Believe me, I'm no genius.

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.

Steve Litt is the author of upcoming books "Samba Unleashed" and "Rapid Learning vi". He can be reached at Steve Litt's email address.

Linux Log: Let's Jettison the Elitism

Linux Log is now a regular column in Troubleshooting Professional Magazine, authored by Steve Litt. Each month we'll explore a facet of Linux as it relates to that month's theme.
UNIX almost died due to its egghead image. Only Microsoft's incredible series of flubs and the timely appearance of Linux saved UNIX from certain death. The authors of those old man page authors didn't believe in empiricism. They didn't even include examples in most man pages. The philosophy was that if the reader was smart enough to use UNIX, the information would simply jump off the man page and into his brain.

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.

Note: You might sense some hypocracy on my part in the previous sentence. I let Windows loving Linux bashers have it with both barrels. But the Windows user who is considering Linux, or has become a part time Linux user, he's the guy I help and mentor. Because I was once like him. 

From now on, every new man page must include examples, a simplest possible proof of concept usage, and references to more documentation. Linux is mainstream now, and many fellow Linux users view it as a tool, not a way of life. Maybe they still need to RTFM, but at least they should have a helpful manual.

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.

Steve Litt is the originator of the UMENU Software Project. He can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process, or articles on tools, equipment or systems with a Troubleshooting slant. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

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

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that by submitting this article I am giving the publisher, Steve Litt, perpetual license to publish this article on Troubleshooters.Com or any other A3B3 website. Other than the preceeding sentence, I understand that I retain the copyright and full, complete and exclusive right to sell or give away this article. I acknowledge that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.
After that paragraph, write the title, text of the article, and a two sentence description of the author.
 

URLs Mentioned in this Issue