Troubleshooters.Com
Presents
Troubleshooting Professional
Magazine
Volume 7 Issue 1, Winter,
2003
Toolsmanship
|
Copyright (C) 2003 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 | Linux Productivity Magazine ]
|
If the only tool you have is a hammer, you tend to see every problem as a nail.
-- Abraham Maslow
|
CONTENTS
Editor's Desk
By Steve Litt
Our air conditioner broke, so we brought in a heating
and air conditioning tech. Watching him work was a pleasure. He was knowlegeable
both in technology and in Troubleshooting Process. And his use of tools was
outstanding.
He had a single tool pouch with almost all the necessary tools and meters.
As he worked, tools came out, and tools went back in. He didn't scatter tools
around. Absolutely no time was lost looking for tools, nor cleaning up at
one work area before moving to another.
Due to price concerns, we had another company actually do the work. They
sent in a tech to evaluate the situation and I watched his tools handling.
Once again, excellent. At all times he knew the location of every tool. He
traced the problem down to a bad outside unit and ordered it.
A team of two techs came with the outside unit. Their tools were different, but their toolsmanship was once again meticulous.
I compared the tool handling of these experts with mine. At Pacific Stereo,
my bosses regularly criticized my housekeeping and organization of my tools.
Realistically, I'd say my tool handling cost me 10 to 15 minutes per repair.
Looking back I realize the only thing that kept me afloat was the fact that
I could diagnose at double or triple speed compared to the other techs. I
used the Universal Troubleshooting Process as a crutch.
Is it any surprise that I later went into software development? All my tools
were neatly organized on my hard disk. It's much easier to keep everything
neat on a hard disk than on a service bench (and certainly than in a dark
and dusty attic). But even in the software field, my tool handling was less than exceptional.
I almost never used a debugger, instead substituting diagnostic printf's
with recompiles. I never really mastered all the power of any editor (until I mastered Vim). Even
my use of computer languages revealed a lack of toolsmanship. Although I've
programmed professionally in over 10 languages, in every language I used
a subset of its capabilities. And yet with all of this, I was usually
the most productive programmer on the project.
Sure, my contemporaries worked wonders with debuggers, editors, and language
features. But with my Universal Troubleshooting Process and the software
design processes I learned at Santa Monica College, I still finished first.
So why complicate my life learning debuggers, editors, and language specific
algorithms?
That question was answered when I saw the toolsmanship of the air conditioning technicians.
This Troubleshooting Professional issue is devoted to toolsmanship. Its benefits and limitations, and how to achieve it.
So kick back, relax, and enjoy this issue of Troubleshooting
Professional Magazine. Now more than ever, if you're a Troubleshooter,
this is your magazine.
Toolsmanship and Bottleneck Analysis
By Steve Litt
Isn't it interesting that I outperform other technologists with far
better tools skills. What's the explanation?
The explanation involves bottleneck analysis. A person troubleshoots as slowly
as his worst skill. I'm slowed by my toolsmanship. But my tool use skills
are a model of efficiency compared to the average person's use of diagnostic
methods.
Even today, about 50% of technologists troubleshoot
by trial and error. It's true that I can lose 10 minutes looking for a tool,
but a trial and error Troubleshooter can lose an hour or even a week using
diagnosis by serial replacement.
What about the other 50%? I'd estimate 40% of them troubleshoot methodically
on a sporadic basis, but it's hit and miss. They lose more time than they
could make up with even the best toolsmanship.
That leaves the 10% who rigorously use a valid Troubleshooting Process. They're
my competition. Assuming they know the technology, the 10 minutes I lose
looking for a tool can cause me to fall behind.
The rules of bottleneck analysis apply to Troubleshooting productivity. You
troubleshoot as slowly as your least developed skill. The trial and error
troubleshooter cannot possibly catch up using excellent toolsmanship and
product and techology knowledge. Giving such a person more technology training
or better tools is like giving a 400 pound rider a lighter bicycle. The weight
of the bicycle is a tiny fraction of the overall problem.
How different things become when the Troubleshooter uses valid process and
has adequate tech knowlege. For such a Troubleshooter, diagnosis
becomes so quick that activities such as disassembly and reassembly, physically
placing diagnostic tests, and the like become a major chokepoint. For this
ninja Troubleshooter, gaining an extra minute with improved Troubleshooting
Process cannot begin to overcome a 10 minute search for the right tool.
Does this mean a Troubleshooter should put off acquiring tool use and handling
skills until he's achieved superior diagnostic performance? Not at all. The toolsmanship habit isn't learned overnight, and
once the technologist has achieved superior diagnostic throughput, she doesn't want to get
stopped yet again by inferior tool use.
So the bottom line is this: superior tools and toolsmanship won't begin to
rescue a Troubleshooter deficient in Troubleshooting Process. But once Troubleshooting
Process and tech knowledge have been removed as bottlenecks, the new bottleneck
is tools usage. At that point, productivity increases proportionally to increases
in tool usage skills.
Improving Your Toolsmanship
By Steve Litt
Here's where the rubber meets the road. How can YOU benefit from this magazine?
So far you've read several feelgood tools articles, and you've read that
in fact my toolsmanship isn't top notch. So how can I teach you? I could
always say "do as I say, not as I do". But we all know that's lame. Much
better advice is to do as the tool experts in in this magazine's articles
-- the air conditioning techs, The Artist, Mr. BabyProofer, the Pacific Stereo technician, and old fat
John. And if you read the Bringing Consistency to Variation article, you'll find that even
though I sometimes spend 10 minutes searching for a socket or C clamp, in my
own way I'm an excellent toolsman.
So I'll interpret the acts of the air conditioning techs, The Artist, Mr. BabyProofer, the Pacific Stereo
technician, and old fat John. And as you read, think of ways you can use
this information to improve your own work.
The Artist is a complete role model for toolsmanship. As you remember, he
produced four high quality paintings per hour using the following three activities:
- Formulate your goal
- Organize and care for your tools
- Perform riffs with your tools
Let's discuss 2 and 3 first, leaving 1 for later...
Organize and care for your tools
Ask any tradesman and he'll tell you your tools are your livelihood. Tools
are expensive. Even cheap tools are expensive, because you keep replacing them when they break.
If you use tools on a regular basis they must be cared for, they must not
be lost, and they must be accessible.
Preserving your tools is a matter of habit. If you're in the habit of putting
your voltmeter in a specific slot on your toolbelt, you'll never leave it
at a jobsite. If you're in the habit of cleaning your paintbrush as soon
as painting is complete, it will never become hard with paint. If you're
in the habit of coiling power cords before putting away your equipment, you
reduce the risk of having them drop and break.
It's a good policy not to loan professional tools. I don't mean you shouldn't
loan the neighbor a rake, but if you're a mechanic you shouldn't loan him
your spark plug wrench. Most people don't take good care of other people's
equipment. And even if they do, loaning the equipment increases the risk
that it will become lost.
Organization
Watch all master toolsmen and you'll see a common trait -- instant access.
The right tool seems to magically appear in the toolsman's hand. No digging
around, no searching, no dropping work materials to reach for the tool. If
diagnosing and repairing a car requires 50 tool tasks (I think that's a reasonable
number for a simple to moderate repair), imagine the difference between a
technician requiring a minute per tool access and a technician requiring a second
per tool access. I count it as 49 minutes difference. The marketplace will bury the
technician requiring an extra 49 minutes per repair.
Of course, nobody gets every tool in 1 second, and nobody requires 1 minute
for every retrieval. But the great toolsman completes many tool accesses
in less than a second, without taking his eyes off the work. And the poor
toolsman might make several accesses in a second or less, and then blow it
by spending 10 minutes hunting down a misplaced tool, or worse, spend an
hour at the store buying a new tool.
Two factors determine the quality of tool organization:
- Knowing where everything belongs (and putting it there)
- Prioritizing
Two air conditioning technicians replaced our outdoor unit. The master technician brought
a torch, lots of plumbing, and 2 or 3 toolbags. He was so familiar with the
placement of his tools that he was able to tell his assistant to "get the
meter out of the side pouch of the toolbag by the bush". Ellapsed time --
2 seconds. Imagine how different it would have been if the assistant had
to search all the bags, and maybe search the bushes too.
Efficient toolsmen know the location of their tools at all times. Each
tool has an assigned place, and the tool is always returned to that place.
And when circumstances prevent returning it to the assigned place, they make
a point of remembering where it is.
Knowledge of location is enough when you have only 5 tools. With 5 tools,
a simple toolbelt is all you need. But most workers use 50 tools. Or 100.
Or more. The reason is simple enough. You could probably complete all necessary
tasks with 5 or 10 tools, but it would be painstakingly slow. Imagine accessing
the sparkplugs on the firewall side of a transverse engine without a flexjoint
wrench, the proper extension, a good light, and maybe a mirror with a clip.
Yes, you can do it, but it could take an hour. If a job takes an inordinate
amount of time, there's usually a tool that can cut the time by a factor
of 10 or maybe even 100.
So those of us with anything but the simplest jobs must work with many tools.
Too many to efficiently access from a toolbelt. Prioritization is required...
Prioritization
Your objective is to reduce average tool access time to less than a second,
and do it without taking your eyes and one hand off your work. If your toolbelt
holds 100 tools, that's not going to happen. You'll feel around for several
seconds, likely dropping some tools, before accessing the right tool.
So with 100 tools you'll not be able to make every tool access under a second.
But using the 80%/20% rule, by putting your 20 most used tools in your toolbelt, with the other 80
tools neatly organized in a nearby toolbox, 80% of your accesses will be
under a second. This simple 2 level prioritization boosts productivity. But
you can do better.
In real life you'll prioritize your tools into more levels. Your top couple
tools will be in your pocket, or in a special pocket of your toolbelt, for
incredibly quick access. Other tools will be in less accessible parts of
your toolbelt.
If you have lots of tools, you'll probably have multiple toolboxes for the
80% of your tools not in your toolbelt. Perhaps the toolbox for the more
common tools will be arranged for quick access -- maybe as quick as a second
if the toolbox is next to you as you work. Toolboxes with lesser used tools
are arranged for findability, even if such findability delays access. Or
perhaps the least used toolbox will simply contain a scramble of tools. If
you access its tools only 2 or 3 times per day, that's not a productivity
problem.
If you're a travelling service person, many of the least used tools remain
on the truck, where you can find them if you need them, but it could be 5-15
minutes access.
The bottom line is that with a little planning, you can drop your average
tool access to a second, no matter how many tools you have.
Thinking Ahead
Tool prioritization takes on a whole new tint when you work on a ladder or
in a small attic. Handling a 60 pound toolbox on a ladder is usually undesirable.
Likewise, you don't want a bulky toolbelt in a tight crawlspace.
In such cases, the hot tip is to think ahead at all the tasks you'll perform
in the "hostile environment", and pack the tools you'll need for those tasks.
Then put them in your pocket or a small toolbelt, and go to work.
Most tree surgeons work in pairs or threesomes. If the guy in the tree needs
a tool, the others put it on a rope and the guy on the tree hauls it up.
But we hired a tree surgeon who worked alone, and it was educational. He
spent 40 minutes on the ground preparing all his tools. He checked the cleats
on the side of his boots. He checked his two waist belts. He checked his
saw, and made sure it was full of fuel. The dead tree was 110 feet high.
How would you like to run out of gas up there.
With all the tools present and checked, he headed on up. At major branches
he'd detach one of his waist belts and put it around him over the branch,
then detach the one under the branch and keep going.
When tree surgeons cut down a pine tree, they cut down the dense part at
the top as a unit. In a team effort, the guys at the bottom pull it to the
side with a long rope, so that when the tree guy saws it off, it falls harmlessly
to the side. What would our lone wolf do?
He tied several loops of rope to one branch, and then to a branch below it.
I mean many, many ropes. Then he sawed the trunk between those two branches,
and the top of the tree fell away, and then got hung by the rope. The tree
shook like a 9.2 earthquake, but the tree surgeon hung on, thanks to his
2 waist belts and his boot cletes. He untied the rope and the entire top
of the tree crashed to the ground.
The rest of the job was just a matter of sawing off 3 foot sections of the
trunk and dropping them down, or sawing off the branches he'd used as perches
on the way up.
I was in awe of the planning that went into this job. I think he knew every
step of the job before he took his first step up the tree. I don't think
a single decision was made while in the tree. This planning enabled him to
bring exactly what was necessary, without hauling extraneous junk up 110
feet of pine tree. This type of planning makes all the difference when working
in less than ideal circumstances.
Perform Riffs With Your Tools
Single second access does no good unless your tasks are performed quickly.
That's where riffs come in. If a job is divided into 50 tasks, it's a good
bet that 45 of those tasks are things you've done many times before. These
should be done quickly, from habit. They're riffs.
Using a ratchet wrench is a simple example. You start by seating the socket
extremely well, bracing the center with your left hand, and really cranking
down with your right hand, all the while taking care that if the bolt loosens
suddenly, you don't bang your hand on something. Once the bolt is loosened,
you either twirl the wrench or ratchet it, depending on how much room you
have. If you ratchet it, you might provide some resistance with your left
hand so the backratchet action doesn't retighten the nut. At some point of
looseness you'll put down the wrench and loosen it by hand, because that's
quicker. But before it comes completely off, you'll make sure to prevent the bolt from falling to the ground or into the car.
Riffs must be quick, automatic and brainless -- based on months or years
of practice. They're habits. Make a strong effort to preform the same tasks
the same ways every time.
On the flip side, always be on the lookout for ways to improve existing riffs,
and invent new riffs to fill a vacuum or replace other riffs. By far the
easiest way to improve riffs or acquire new ones is to watch others work.
When you see someone cut 30 seconds off your time on a task, see what he's
doing, evaluate it, and incorporate it into your work. Often the better riff
will involve a different tool. If so, use that tool. If you don't have it,
buy it. Remember the story of the drills at Pacific Stereo?
How do you walk the tightrope between maintaining habitual riffs and improving
them? Simple. Evaluate which riffs could use improvement. A 1 second task
needs no improvement unless you do it hundreds of times in the course of
a repair. On the other hand, a 5 minute task in an hour repair is definitely
a candidate for improvement, so be on the lookout. If you ever find yourself
angry and cursing at a particular task, that's a sure sign you need a
better riff, possibly involving a different tool.
Long ago I had a 1982 Buick Lasabre with the fuel filter built right into
the carburetor. Every time a mechanic changed that fuel filter it was a 40
minute operation. Succeeding mechanics increasingly stripped the threads
of the fuel filter housing, until finally I had to have the carburetor removed
and re-tapped. Finally I took the car to Gary's Unocal in Reseda, and Gary
showed me the right way. He had a special wrench he put on one hex, and he
put a normal open end wrench on the other, loosened, pulled one end back,
replaced the filter, carefully re-threaded by hand, and tightened. Ellapsed
time -- 5 minutes with no thread stripping. Riffs make all the differences.
Riffs Drive the Tools
Because riffs use tools, one might surmise that tools drive the riffs. But it's the reverse. Riffs drive tool usage.
Take the case of Pacific Stereo. With over 10 screws per stereo, we all got
very good at manipulating hand screwdrivers. But "skinning" and reassembling
the case continued to require about 5 minutes -- there was only so fast we
could twirl a screwdriver. One tech recognized the inadequacy of his screw
removing riffs, and devised a better riff based on an electric drill.
At the factory, "old fat John" realized that the gloved hand riff took too
long, and went on the lookout for a new riff. His alerted mind soon focused
on using a board as a tool to support an improved riff. Mr. BabyProofer didn't
carry his two drills as a status symbol. They were tools to support his lightning
quick riffs.
Access Speed vs. Riff Speed
As a bicycle mechanic (between my factory career and my stint at Pacific
Stereo), I used an adjustable wrench for all nuts and bolts. Adjustable wrenches
can be incredibly slow -- especially in tight quarters such as the angle
adjustment nuts on old-fashioned seats. I tried using a ratchet and sockets,
but gave it up. The time I saved loosening and tightening was more than consumed
by the time required to locate and replace sockets on the wrench. "Universal"
tools convey a heavy benefit in access time, even if they're not riff-efficient.
Hindsight is 20/20, but if I had my bicycle mechanic days over again, I'd
have followed Mr. BabyProofer's lead and bought multiple ratchet wrenches,
each with a different hex head. And I've had used a tool pouch. I'd have
picked the top 4 most used hex heads, and I'd have color coded them. That
way I could have gotten 1 second access and yet benefitted from ultra-quick
tightening and loosening.
Recently, as a recreational bike rider, I've encountered a problem. For years
I've carried all tools in a tied up bluejean leg. That works well for rare,
intense tasks like changing flats. But lately I've had increased need for
on-ride brake and derailleur adjustments. Crowded with tools, the fastest
access method is to untie the bluejean leg and spill all the tools on the
ground. There are about 30 tools.
Spilling and replacing the tools takes 5 minutes. That's not much of a penalty
in a tire change, but it changes an adjustment from a 1 minute to a 6 minute
job. So I purchased a handy-dandy 17 in 1 Crank Brothers tool assembly with
all size allen wrenches, and a philips and flat screwdriver. I'll add a spoke
wrench, and then put them in a tiny seat pouch for quick access on a ride.
For more challenging jobs, my bluejean leg will be available.
Choosing Tools and Riffs
Watch an expert at work. See what he does with mirrors. See what he does
with coathangers. With lights and magnifying glasses. With flex-shaft wrenches.
With power tools.
Watch the expert with his meters. See the various clamps and probes. See
him use an icepick to make contact with painted or oxidized surfaces. Notice
the induction ammeter he uses to remove the necessity of disconnecting wires.
Special use tools abound for the person with riffs to use them. Reverse drillbits
can remove sheared off bolts. Taps can rethread messed up threaded holes.
Various lifting devices can hoist heavy objects. Magnets can be used to retrieve
otherwise irretrievable steel objects. Magnetized screwdrivers can be used
to thread screws where you'd otherwise need a half hour disassembly and reassembly.
POST (Power On Self Test) cards are available for computers to determine
the problem in a no-boot, no-video computer.
Sometimes cheap tools replace expensive tools. Upon moving from Pacific Stereo
to George Meyer TV I discovered George Meyer had no Variacs for current limiting,
and didn't want to spend the money to purchase one. No problem -- I rigged
up a series lightbulb. I also replaced a hard to use distortion analyzer
with my ears to determine if a sine wave was distorting.
Riffs are quick habits, and should be done the same way every time, UNLESS
the current riff is difficult, dangerous, frustrating, expensive or time
consuming. If the current riff isn't efficient, look for a new riff. Watch
others at work. Ask acquaintences and ask on the Internet. Look through tool
catalogs. If you have trouble with the task, you're not alone, and probably
somebody sells a tool to make quick of the task.
Formulate Your Goal
Back to The Artist's methods, remember he started by formulating a goal.
On first impression, formulating the goal has nothing to do with toolsmanship.
But closer scrutiny paints a different picture. Your goal determines what tasks you'll perform, which in turn determines what
tools you'll need. And unless you've been given a blank check and infinite
training time (as well as an infinite brain), your tools and riffs determine
the goals you can take on.
It's no accident that The Artist didn't paint football players or skyscrapers.
He had no football player or skyscraper stencils. He had no riffs for football
players and skyscrapers.
Correct goal formulation is your response to finite tools and riffs. The
narrower the range of goals you persue, the tighter you can make your riffs,
and the more you can slaughter the competition. It's marketing 101 -- pick
your core competancy and specialize.
It's not quite that simple, as any blacksmith or Cobol programmer can tell
you. When the marketplace walks away from your core competancy, your range
of goals must change. If you're paying attention, such changes can be slow
and incrimental. Estimate future markets, decide on your goal range, and
obtain a few additional tools and riffs to accommodate that goal range. Leverage
your existing tools and riffs to the extent possible. Rapid Learning techniques are your friend.
But what if, by its very nature, each job you take on is different? With
such a wide goal range, how can you acquire tools and riffs? Welcome to my
world...
Bringing Consistency to Variation
By Steve Litt
On an average day I'll program in 2 different languages. I've had many 4
language days. In an average week I'll troubleshoot computers, networks,
and maybe 5 different software applications. I regularly design magazine
articles, books, and course material. I perform sales activities.
On the surface this would appear to require such a broad set of tools and
riffs that depth would be impossible, and if depth is impossible, I would
lose in the marketplace. But this is just a surface appearance.
The trick is to find common denominators in all this work, and master tools
and riffs consistent with those common denominators. Faced with the necessity
of fixing mechanical, electronic, networking and software devices, I devised
the Universal Troubleshooting Process, a system independent tool for troubleshooting.
So no matter what I'm fixing, here's my list of major riffs:
- Prepare
- Make a damage control plan
- Get the symptom description
- Reproduce the symptom
- General Maintenance
- Narrow the root cause scope
- Repair or replace the defective component
- Test
- Take Pride
- Prevent future occurrence
Works on anything. What happens if a problem stumps me or causes me to panic
or become angry? No problem, I've seen that situation before, and I know
the riff. The riff uses a tool called "The Troubleshooter's Mantra", and
consists of simply asking myself "how can I narrow this down just one more
time?". Computers, networks, software, source code, electronics -- it doesn't
matter -- if I'm fixing it, these are my tools and riffs.
I write software, magazine articles, and books. What's the common thread?
Design. All of these things must be designed in order to come out right.
I have two design methodologies -- functional decomposition for structured
program design, and entity relationship diagrams for OOP programming. And
lucky me -- functional decomposition can be used to design books and projects.
Luckier still, I have a software tool, an outline processor called VimOutliner,
that's perfect for functional decomposition.
On the surface it looks like my activities are disparate. But on closer scrutiny
I do two things over and over again -- design and troubleshooting. And I've
obtained tools and mastered riffs for these two activities.
You might observe that there's more to writing programs or books than design
and troubleshooting methodologies. There are computer languages to master,
including every language's little tricks and shortcuts. There are debuggers
to master -- often one debugger for each computer language. There are editors
to master, and often editors are integrated with the development environment.
Your observations are correct!
So now you know why I'm regularly accused of writing Perl, PHP, Python and
C++ with a C accent. C is my native language, so I regularly use C algorithms,
often increasing the line count of my programs. If you've seen me debug,
you know I seldom use debuggers. With so many language dependent debuggers,
diagnostic printf's are easier for me.
Remember the discussion of Access Speed vs. Riff Speed in the Improving Your Toolsmanship
article? When accessing (meaning learning) specific debuggers is too time
consuming, I use the one size fits all tool, diagnostic printf's. When accessing
specific optimal language syntax is too time consuming, I use one size fits
all algorithms. What I lose in riff speed I gain in access time. And remember,
I have the huge advantage of consistent design and troubleshooting tools
and riffs, putting me way ahead of the crowd. So if you read my plain-vanilla
code, rest assured there's method to my
madness.
Besides my methodologies, I also have advantages in content creation
software. I can make the Vim editor walk and talk. My VimOutliner software
is the world's fastest outline processor, and I know it intimately. When
it comes to the Mozilla Composer WYSIWYG html creation tool, there are few
faster than me. And I've recently become adept enough at LyX to write a 117,000
word book in LyX (Troubleshooting Techniques of the Successful Technologist).
Summary
If you're lucky enough to perform the same type of work every day, take advantage
of that fact to go deep with your tools and riffs. But if your work varies
so much that the quantity of tools and riffs exceeds your ability to go deep
with them all, find the commonalities in your various jobs and then form
riffs to handle those commonalities, and tools to support those riffs.
Intangible Tools
By Steve Litt
Most of this Troubleshooting Professional issue has focused on tangible tools
-- wrenches, screwdrivers, meters and the like. And we also covered the intangible
tools called The Universal Troubleshooting Process, functional decomposition
and entity relationship diagrams. There are many, many more intangible tools
in the software world.
Text editors, outline processors, word processors, html authoring tools,
xml authoring tools, debugging tools, web browsers, menuing programs, communications
programs such as email, newsgroups and instant messaging, financial software,
in-house productivity and ERP programs, and much, much more.
In once sense access to software is instant. Unlike a toolbox, a hard disk
can hold thousands of software tools neatly sorted. You'll need a menu system
configured to quickly run the software tools. Often used software is usually
closer to the root level of the menu. The menu itself must be fast. I use
UMENU, an Open Source keyboard-only menuing system (links for download in
URL's section).
Another aspect of access is the time it takes to learn a tool. With most
hand tools that time is negligible, but with software it can hours or even
weeks. This learning period often causes people to use "one size fits all"
type software tools, an equivalent of the adjustable wrench. At one time
I used Microsoft Word to write letters, books, and outlines. Now I use the
Vim editor as the engine of my outliner (VimOutliner), as a source code editor,
as a phonebook, and to write simple documents.
Riffs with software tools are almost infinite. Your fingers learn the necessary
keystrokes, or the required mouse strokes. There are often several different
software tools to accomplish the same things. When riffs start taking more
than a few seconds, or when they start being hard to remember, different
programs can be combined with a script to accomplish a task that each
piece alone couldn't have. This is particularly true in command line rich
operating systems like UNIX, Linux and BSD. But thanks to the marvels of
scripting languages like Perl and Python, you can create substantial scripts
in primary GUI operating systems like Windows using the Python or Perl languages
freely distributed by ActiveState (URL in URL's section). If you're a Macintosh
user, and if you have OS/X, you're in luck because OS/X is BSD Unix under
the hood, so you can install Python or Perl for UNIX on it.
As a touch typist, my personal observation is that keyboard-based riffs are
much more productive than mouse based riffs except in drawing programs. Many
pieces of software make efficient use of the keyboard. So if you're a touch
typist, seek out those keyboard friendly programs. Once again, if you'd like
a keyboard driven menu program, the UMENU program with the EMDL menu authoring
system is an excellent choice. Both URL's are in the URL's section of this
magazine.
Between your menu program, the software you use, and the scripting you do,
you can achieve incredible productivity with your software, often increasing
productivity by more than a factor of 10.
The State of Troubleshooting Address
By Steve Litt
With respect to Troubleshooting, 2002 was more evolutionary than revolutionary.
Troubleshooting Process continued making inroads into corporations, in large
part assisted by Troubleshooters.Com. Nevertheless, there's plenty of room
for improvement in employee rank and file.
We Troubleshooters are still losing the battle with complexity. Although
complexity has increased in the auto industry, at least quality and diagnostic
tools have kept pace. Casual shadetree mechanics have pretty much been rendered
obsolete, but the state of auto repair and reliability is probably as healthy
as ever.
The Windows operating system was the greatest source of complexity in previous
years, but I've heard that Windows XP is at least more reliable than its
9.x and ME ancestors. The bad news is that Microsoft appears to be increasing
complexity along with the reputed reliability increase. After being granted
a legal monopoly by the Justice Dept, they appear to be packaging more and
more into their operating system and their other applications. This includes
plans in future Windows versions to include "Digital Rights Management" (DRM),
a copy protection scheme whose advertised purpose is to reduce "piracy" and
other theft of intellectual property. However, DRM can also be used to reduce
interoperability, needlessly complicating system integration, and even such
mundane tasks as backup and system synchronization. If you're in a position
to choose software products, please keep this in mind.
Automation Assisted Troubleshooting Process (AATP), which I formerly called
"Era 4 Troubleshooting", has been too expensive to implement universally.
AATP has made inroads in the military and the automotive industry. But until
AATP authoring becomes more affordable, universal adoption will not happen.
That's too bad, because the AATP tool has the potential to create incredibly
quick and effective riffs.
Troubleshooting Professional Magazine certainly changed this year. After
years of supporting the dual audience of Troubleshooting Process experts
and Open Source advocates, TPM spun off a new monthly magazine, Linux Productivity
Magazine, while Troubleshooting Professional became a quarterly magazine
publishing all troubleshooting all the time. In my personal opinion, both
magazines became much better now that each is free to focus on its core audience.
The 2002 economy was horrible for technologists of all stripes, and there
was no magic bullet to avoid the unemployment line. Certainly security expertise
is helpful. Troubleshooting productivity is also helpful. Before they turn
out the lights and shut the doors for the last time, even the most financially
distressed companies need people who can quickly and correctly solve technical
problems. That's our silver lining.
I don't expect the economy to improve in 2003. Believing that the populace
thinks only of foreign affairs, the powers that be don't see the economy
and incredibly bleak employment picture as a problem. The voters will let them know they're wrong
in 2004, at which time the economy will improve, but we still need to survive
2003. As a Troubleshooter, you want to hone your Troubleshooting skills,
and also transition your technical skills to those of most value in the current
marketplace. With the current economy, company paid training is rare, so
you'll need to use Rapid Learning techniques.
Recessions and depressions are times of repair rather than new purchases.
Try to position yourself as the person who makes new purchases unnecessary.
And please try to remember the long term -- neither boom times nor recessions
last forever. Hang in there.
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.
Any article submitted to Troubleshooting Professional Magazine must
be licensed with the Open Publication License, which you can view at http://opencontent.org/openpub/.
At your option you may elect the option to prohibit substantive modifications.
However, in order to publish your article in Troubleshooting Professional
Magazine, you must decline the option to prohibit commercial use, because
Troubleshooting Professional Magazine is a commercial publication.
Obviously, you must be the copyright holder and must be legally able
to so license the article. We do not currently pay for articles.
Troubleshooters.Com reserves the right to edit any submission for clarity
or brevity, within the scope of the Open Publication License. If you elect
to prohibit substantive modifications, we may elect to place editors notes
outside of your material, or reject the submission, or send it back for
modification. 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):
Copyright (c) 2001 by <your name>. This material
may be distributed only subject to the terms and conditions set forth in
the Open Publication License, version Draft v1.0, 8 June 1999 (Available
at http://www.troubleshooters.com/openpub04.txt/ (wordwrapped for readability
at http://www.troubleshooters.com/openpub04_wrapped.txt). The latest version
is presently available at http://www.opencontent.org/openpub/).
Open Publication License Option A [ is | is not] elected,
so this document [may | may not] be modified. Option B is not elected,
so this material may be published for commercial purposes.
After that paragraph, write the title, text of the article, and a two
sentence description of the author.
Why not Draft v1.0, 8 June 1999 OR LATER
The Open Publication License recommends using the word "or later" to describe
the version of the license. That is unacceptable for Troubleshooting Professional
Magazine because we do not know the provisions of that newer version, so
it makes no sense to commit to it. We all hope later versions will be better,
but there's always a chance that leadership will change. We cannot take
the chance that the disclaimer of warranty will be dropped in a later version.
Trademarks
All trademarks are the property of their respective owners. Troubleshooters.Com
(R) is a registered trademark of Steve Litt.
URLs Mentioned in this Issue
- Mr. Babyproofer
- The Artist
- Process Tools