What makes a good problem solver(learner)?

[dastructhm]

when it comes to learning new things in EE, such as, learning to use a new part, like the schematic of FT232RL.

Why do some people learn faster than others do. Why would somebody simply give up, while others succeed and continue to take it to the next level?

[xrunner]

Why do some people learn faster than others do. Why would somebody simply give up, while others succeed and continue to take it to the next level?

Why? I don't know.

Has to do with a person's psyche, which I don't think can be easily explained. I know I can't explain why.

[Halcyon]

1. Don't assume you already know, listen to others. Best case, you might learn something new or a better way to do something. Worse case, you come out of there with the reaffirmed knowledge that you were right.

2. Don't exceed your knowledge.

[tooki]

Experience is a big thing, since it helps you know what things to look for and what to gloss over.

[fourfathom]

2. Don't exceed your knowledge.

I don't know about that.  I've learned a lot by taking on projects that exceeded my knowledge.  That's the best way for me to expand what I know.

[PlainName]

I think it's two things:

1. Applying logic to a collection of data about the problem.

2. Being able to collect the data to which you can apply logic.

Experience is a big help in the collection because you'll know what sort of thing to look for, and how to see it. But you can brute force that bit if necessary - sometimes I'll just play with whatever to see what happens and eventually some pattern or associated symptoms will become obvious.

In the end, though, it's the ability to be able to say it can't be this possibility because that data would be different, and then you just run through logically excluding all the possibilities until there's just one left. Or maybe a couple if you didn't get enough relevant data points.

Experience also lets you say "Ha, I've seen this before" and go straight for the jugular. And then when it turns out not to be you'll recall that tiny symptom you somehow missed in the rush which pointed at something else.

[EPAIII]

Some years ago, back in the late 60s, I had my first civilian job at a TV station which had replaced most of their technical (engineering) staff. After just a couple of weeks of training I found myself on the Saturday evening shift and almost everything in the control room was not working properly. I was one of three persons in the building; a receptionist and a radio disk jockey were the others so zero help there. I desperately called every number I had: chief engineer, CEO (former chief engineer), and several others. But had no luck contacting any of them: just left messages. I was on my own.

By the time a couple of the ones that I had shown up, I had solved the problem.

How?

Well, a basic knowledge did help. I did understand how the place functioned, if not in all the particulars, then in general. But I tackled it. And kept at it until I found a rack full of tube equipment needed a bit of a nudge to re-establish a loose contact. A footprint, at about waste level on the next rack over, helped. That rack of tube chassis was the station's sync. generator and the signals generated there went to almost everything else to provide the timing needed.

What I learned and what I took with me for the remainder of my 45+ year life as a TV engineer was one word:

PERSISTENCE!

The first thing you MUST have when confronted with a problem, electronic or not, is persistence. You need to keep at it until it is solved.

Sometimes "keeping at it" is challenging. And a number of other techniques can be employed to do so. Ask for help from others (that was my first thought that day). Study what you know about the problem, no matter how little that may be.

Something I learned from a lecture some time after that incident was to try to mentally put the problem in a BOX where you know everything going into that box is OK and what is coming out is not. Then try to divide that box in half (or some fractions) in a manner where there is only one or just a few things (signals in electronics) that cross from one half to the other half. Then test those things (signals) to see if one or more is bad (problem is in first half) or if all are good (problem is in second half). Then divide the bad half again and repeat until you are down to THE bad part.

I have used other techniques to "keep at it". Sometimes when I was stumped with a problem in a machine where just the schematics took up a complete 3" size, three ring binder, I would look at one of those schematic sheets (14"x22" or larger) and make my best guess as to which part it was. Then I would replace that part and see if it did any good. That, at least, eliminated one possibility. And I kept at it.

Sometimes a break or lunch helped. I once got an insight while ordering a sandwich down the street. After eating I tried that hunch and sure enough, that was it. My brain apparently kept working on the problem while I was trying to address my stomach's needs.

But, IMHO, it all comes back to that one work,

PERSISTENCE!

[fourfathom]

And look at the problem from different angles -- sometimes literally.  On a few occasions I have taken a (paper) schematic and turned it upside down, forcing myself to look at it without making any assumptions.  You often see what look like familiar patterns that turn out to not quite as you initially thought.

This also works when creating something new.  Don't accept your first impression of the problem (I consider a new design or system to be a problem that want to solve.)  Mentally spin it around, and see if you can identify an underlying pattern or structure.  There may be more than one way to solve it, but some are cleaner or faster or easier or more flexible or cheaper than others.  One analogy I like is when you are driving by an orchard or other crop planted in a grid pattern.  You will see many patterns and ratios appear.  Some are hard to see (1:7) and others (1:1) jump right out when you are in the right orientation. 

For me this may take a while, and I would often confound my bosses in the early stages of a project because it appeared that I was just lounging at my desk.  Perhaps a few weeks would go by with no apparent progress.  I would usually carve off a small piece of the puzzle and launch that design, just to keep the boss happy, but the big picture takes time to get right.

[Halcyon]

2. Don't exceed your knowledge.

I don't know about that.  I've learned a lot by taking on projects that exceeded my knowledge.  That's the best way for me to expand what I know.

You raise a good point and I always encourage people to challenge themselves. But in a professional environment, you'd be expected to do your homework and sought assistance before you did anything. For example, you wouldn't start tinkering around on a production system if you didn't know what you were doing. In a testing/development type environment, sure, go nuts!