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.

The Loser

By Steve Litt
Furtively looking around, he dropped the coins in the phone. This was a call he didn't want anyone from Pacific Stereo hearing. It's bad enough if your employer knows you're looking, but for an electronic technician to apply for a janitor job -- that's a sure sign of a loser.

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...

9 Months Later

He got ten congratulatory phone calls his first hour at work. Word was out all over Pacific Stereo. His co-workers shook his hand and marveled at his accomplishment. The female cashiers all gave him the eye and wondered why they hadn't noticed him before. The December Technician Production Report listed him as #2. His $7411 production and the top technician's $8700 both broke the former production record. His commission for the month substantially exceeded the paychecks of his engineer friends. He smiled as he contemplated how good life had been the last few months.

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".

4 Years Later

He'd found the defective chip in the minicomputer, after a parade of programmers and hardware people failed. He was a junior programmer, but his Troubleshooting ability made him a top member of the team. They sent him when everyone else failed, and he always got his bug. By now he had Divide and Conquer and the Mental Model down to a science, and could fix anything. As time went on, his Troubleshooting ability opened ever more important doors. In 1990 he wrote a book called "Troubleshooting: Tools, Tips and Techniques",  in 1996 he became the webmaster of Troubleshooters.Com, and in 1997 founded an online magazine called Troubleshooting Professional Magazine.

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.

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