This is a question that cuts across most fields. I have a young tech that I
am training and attempting to accelerate his development as much as
possible. Recognizing that it takes years of doing repairs to master the
skills involved in troubleshooting and repairing electronics, I still want
to make him as useful as possible as quickly as possible. If anyone has
suggestions I welcome them.

I see most problems solving as a matter of both inductive and deductive
reasoning. The ability to use both, recognize when either is getting you to
the result needed, recognizing when your assumptions need to be checked,
your facts need to be checked, and your steps in reasoning need to be
checked is key to effectively fixing things.

My method is essentially to give him jobs that I know he can complete, but
also give him the ones that I know he will get stuck on and as he gets
stuck, talk him through the process that I would use to figure out the
problem. My basic routine is to gather the information (complaint and
related info, observe the symptoms and condition, look for the obvious,
etc), search my memory, notes, and databases for info relevant to the
problem and device, block diagram the system mentally, then break it down
into the likely areas of the problem.

Where I see him (us) getting stuck is often due to the assumptions made,
both about the system and about the facts found. The solution is often to
gather more facts (use the scope, dumbass), but often also to test the
conclusions that we come to that are based on preconceptions and
expectations. Of course, we get to be efficient in this business by
recognizing patterns and getting to the problem quickly, but there has to be
a balance between the two extremes of treating everything as symptom-repair
(inductive) and getting mired in making measurements and test set-ups
(deductive). Walking that line can make the difference between an efficient
and profitable shop and one that fails.

Any suggestions or discussion of your methods?

Leonard