Breaking News
Comments
JanineLove
User Rank
Blogger
Skills
JanineLove   7/26/2013 11:08:15 AM
NO RATINGS
Hi Larry, I'd like to hear more about your ideas for training people to trouble shoot.

JanineLove
User Rank
Blogger
Re: Skills
JanineLove   7/26/2013 11:09:18 AM
NO RATINGS
Any troubleshooters out there who want to give a shout out to a professor/mentor/program that helped them better their mad skills?

Frank Eory
User Rank
CEO
Re: Skills
Frank Eory   7/26/2013 4:54:37 PM
NO RATINGS
There is no substitute for gaining hands-on experience at troubleshooting failing circuits in the lab. The more strange things you see and eventually solve, the better you get at it.

It helps to know the system inside and out, and have a thorough checklist that starts with the most basic things like assembly errors and verifying correct supply voltages at all the right places.

Once you work your way through the list of most probable causes and still haven't solved the mystery, start working through the list of improbable causes. Think outside the box, and start visualizing all those invisble resistors, capacitors and inductors that aren't on the schematic. Remind yourself that although what you're observing might seem impossible -- that the circuit should never behave that way -- the fact is, circuits don't lie, and there are no displeased "electron gods." Physics governs, and when you finally find the root cause of the problem, it will seem so obvious that you will wonder why you didn't see it sooner.

Peter Clarke
User Rank
Blogger
Re: Skills
Peter Clarke   7/29/2013 5:24:30 AM
NO RATINGS
There are also some tricks that probably seem obvious to most readers, but things like dividing the problem temporally and physically.

SO you try and trace forward to the point where abnormal behavior first appeared...or trace backward through time all the points where the abnormal behavior existed to try and find a point of injection.

Similarly if you can cut away parts of the circuit as being OK, what is left should be the most likely source of the error.

All good Sherlock Holmes stuff. "When you have eliminated the impossible, whatever remains, however improbable, must be the truth."

And always check your assumptions.

Very often the source of the problem that escapes detection for a long time is some fact or condition that was not deemed worth checking.

 

 

Larry Desjardin
User Rank
Blogger
Re: Skills
Larry Desjardin   7/29/2013 10:22:02 AM
Peter,

Yes, I think there are some skills that can be taught.  Dividing the problem down to find the subsystem that is causing the error is clearly a general tool. 

There are also classes of errors that are easier to debug than others.  Construction errors, for example.  This is true for hardware or software.

As the problems get more rare and exotic, the more difficult the investigation.  Divide and conquer works, as long as you know all the subsystems you are dividing by. How could you not? I've seen digitial timing issues (think jitter), where engineers were dividing the problem into the different circuit blocks. The culprit was cross-coupling through the common power supply.  In the engineer's mind, the different digital blocks were the subsystems, the power supply wasn't even considered.

Here's another one. Cosmic rays changing a memory value.  Ultra-reliable systems deal with this issue.  

Peer reviews can be very helpful.  Someone has a thought or a previous experience and looks at a problem in a new way.

Many years ago, HP was experiencing reliability problems with an exotic semi fab.  "Phantom" sodium doping was appearing in the devices, which eventually migrated and caused a failure. The equipment and process was checked and rechecked. Perfect. The wafer was watched all through the process. Perfect.  How could this happen? Turned out the night crew used one of the ovens occasionally to warm up their pizza.

 

DU00000001
User Rank
CEO
Re: Skills
DU00000001   7/29/2013 12:40:06 PM
NO RATINGS
Sorry, I've never seen a professor, program or ...
Subsequently you will find an abbreviated description of how I'm personally addressing the more or less frequent 'taskforce' jobs with quite some success.

The very core of troubleshooting is root-cause-analysis, which starts with a long list of 'is'/'is not' statements.
In other words: list, which effects are correlated with the 'misbehavior' and which are not. This stage of analysis does not necessarily require profound system knowledge. But it helps to know how "things" are done (= implemented, 'solved', ???) 'normally'.

Having compiled a reasonable list of 'is'/'is not', proceed from correlation to causality analysis. That is: find out which physical or 'side' effects could cause the effects observed. This is the stage where profound knowledge of building blocks is at least helpful.

The rest is about measuring, probing, testing, modifying, iterating, ... Whether short or long, following the path described above routinely leads to results.

'Experience' (own or learned from others' faults) helps to speed up things (or to stay in the tracks) but there is always a first time.

chanj0
User Rank
Manager
Understanding of system and more importantly,...
chanj0   7/26/2013 12:51:21 PM
NO RATINGS
Troubleshooting is absolutely one of the most important skills to be a good engineer, in my opinion, to be a good manager. Question is what knowledge we all need to be a good troubleshooter. To me, the thorough understanding of system is very important. W/O understanding, I, at least, will have hard time to start. However, documentation may not be always available. Even it does, it may not cover the whole 9 yards that you will need to get the job done. So, what else? Experience. I remember the first undergraduate project years back - a class A amplifer. The first symptom is it doesn't even ampilifer any signal. After sometimes, I just found out the transistor was blown to begin with. Understanding how transistor works definitely come handy. The 2nd symptom after signal was coming out of the output - noise and signal clipping. Apparently, power supply didn't give a clean voltage and amplification was larger than calculated. With twist of resistor and building of feedback loop, the issue was relief. This is a simple project and yet, I have learned a great deal as a freshman in engineering school. Later on, with years of on the job training, when I became manager, I was able to build a checklist to troubleshoot and guide my subordinates to resolve most issues in a timely manner.

Susan Rambo
User Rank
Blogger
Re: Understanding of system and more importantly,...
Susan Rambo   7/28/2013 1:25:23 AM
NO RATINGS
A primer in general systems theory might be helpful.  Do engineering schools provide that at all?  Understanding of fundamentals like unintended consequences and the like ought to be second nature to engineering graduates!!

betajet
User Rank
CEO
Detective Novels
betajet   7/27/2013 12:08:26 AM
NO RATINGS
A student once asked me how I learned how to debug.  I hadn't really thought about it before, but after considering the question a bit I told him it was probably the many detective novels I read as a teenager.  I think the best genre for this is the "police procedural", such as the Martin Beck series by Maj Sjöwall and Per Wahlöö (e.g., The Laughing Policeman) and Georges Simenon's Maigret novels.  A police procedural puts you in the right frame of mind for the slow, methodical process of tracking down a bug.  An anomaly has occurred.  First you try to reproduce the crime.  Then you have to interview all the signals and/or variables that may know something about the crime.  You have to assume that some or all of them are lying to you.  You have to eliminate suspects until only one is left, or else get lucky and find a key clue or get an unexpected report from an informer.  You have to look for Joseph P. McGillicuddy, Lt. Dan Muldoon's code name for the suspect they don't know about -- yet -- in The Naked City (Jules Dassin, 1948).  Trying to hurry the process makes you miss things.  You neglect to follow up an unpromising lead that ends up solving the puzzle.

Private detective novels are also good, especially the complex Ross McDonald and Raymond Chandler novels that have so many characters that it's hard to keep them straight.  Rex Stout's Nero Wolfe novels are excellent, because they also have the police procedural form, with Archie Goodwin and other operatives bringing the information to Nero Wolfe, who is the only one who can fit all the pieces together.  Another favorite is John Dixon Carr, master of the "locked room" mystery.

When I have a really tough debugging problem and I can't seem to get there, I put on my hat -- an authentic English deerstalker such as is worn by Sherlock Holmes.  It always puts me in the right frame of mind to reëxamine the evidence one more time and see what I missed before.


The worst thing you can do?  Look at your design or code and say "it's got to work!"  Obviously it doesn't, so assuming otherwise is not going to put you in the right frame of mind for debugging it.

rich.pell
User Rank
Blogger
Re: Detective Novels
rich.pell   7/27/2013 9:11:10 AM
NO RATINGS
"A student once asked me how I learned how to debug.  I hadn't really thought about it before, but after considering the question a bit I told him it was probably the many detective novels I read as a teenager."

Or perhaps you were drawn to such material because you already possessed a problem-solving "gene"  - a trait that I suspect may be common among engineers.

Susan Rambo
User Rank
Blogger
Re: Detective Novels
Susan Rambo   7/29/2013 3:50:59 PM
NO RATINGS
@betajet, A student once asked me how I learned how to debug.  I hadn't really thought about it before, but after considering the question a bit I told him it was probably the many detective novels I read as a teenager.  

It makes a lot of sense that a love of detective work (as manifested by your love of the detective novel) -- and not just a love of "problem solving" -- would help explain what keeps an engineer in engineering. It must take a huge amount of patience to be an engineer. I've heard airline pilots describe their jobs as "hours of pure boredom, seconds of sheer terror." What is the electrical engineers equivalent? Hours of frustration and hard thinking, followed by seconds of high fives, then on to the next problem? I'm sure you can say it better. 

betajet
User Rank
CEO
Re: Detective Novels
betajet   7/29/2013 7:16:41 PM
NO RATINGS
Debugging a difficult problem is mentally exhausting (at least for me) because you have to concentrate hard on the likely causes while at the same time keeping your mind relaxed so that you can think of unlikely causes.  Then you have to find test cases to reproduce the bug reliably and instrument the hardware or code to figure out when and where it's happening.  I do get a thrill when I've figured out what subtle or stupid error caused the bug, but it's combined with anxiety that maybe it's really something else, especially if it's not completely obvious how the bug is causing the observed misbehavior.  So the high-five is tentative.

So while I find debugging a (usually) satisfying challenge, it's not the part of engineering I like best and I try to design hardware and software that won't need debugging.  I think of engineering as an art form: creating beautiful, elegant hardware and software and user interfaces that are a joy to work with rather than just hacking together something that seems to function properly.  Many engineers share this view: Steve Wozniak talked about being an artist-engineer at his 2011 Embedded Systems Conference "fireside chat", and at a 2012 Design West forum Raspberry Pi engineer Gert van Loo said that engineering is the best way to make a good living doing art.

There's a story about the artisan who made the beaten copper doors for the Tsar of Russia.  He would take a large plate of copper, and pound it with a hammer, over and over and over, creating beautiful swirling patterns.  Someone asked him: "How do you know when it's finished?"  He answered: "It's never finished -- I keep pounding until they take it away from me."  Engineering is like that: we'd always like to make it better, but at some point they take it away so they can ship it.

Susan Rambo
User Rank
Blogger
Re: Detective Novels
Susan Rambo   7/29/2013 9:43:34 PM
NO RATINGS
@betajet, while I find debugging a (usually) satisfying challenge, it's not the part of engineering I like best and I try to design hardware and software that won't need debugging.

Good point. If you practice your craft well, you can maybe reduce the time you spend debugging. 

Subra0
User Rank
Rookie
Re: Detective Novels
Subra0   8/2/2013 4:22:36 AM
NO RATINGS
Hey Susan 

People do ask me this question - infact I do ask myself the same question : how did I learn to troubleshoot ?  

Like you said - lots of hard work, hours of poring over circuit diagrams, board layouts, datasheets and probing until the final "AHAa" moment. And remorse , ofcourse, kick myself for having made the mistake in design.

Also as we get on in age, managing to recall similar problems encountered - experience isin'it ?

Subra

kfield
User Rank
Blogger
Learn from others
kfield   7/27/2013 2:05:03 PM
NO RATINGS
I couldn't agree more about the critical need for good troubleshooting skills in engineering, having launched several new content sections on EE Times and Design News like Engineering Investigations and Made by Monkeys, where engineers relate stories involving mysterious problems and how they were resolved. Though nothing takes the place of hands-on experience, I think that engineers can learn from the story-telling by other engineers on problems they solved. Detailing their thought process of what they tried and why and what worked and what didn't work is an important transfer of hard-earned experience. 

bertgoz
User Rank
Rookie
PDP-11
bertgoz   7/29/2013 5:08:27 AM
NO RATINGS
Just out of curiosity, where can I learn more about the PDP-11 and its metastability problems?

Larry Desjardin
User Rank
Blogger
Re: PDP-11
Larry Desjardin   7/29/2013 10:01:31 AM
bertgoz,

The PDP-11 had a multi-bus architecture between computers.  Any computer could request the bus, and the one that requested it first got it. It worked well, but what happens if they request at the same time? At EXACTLY the same time.  It's like clocking a flip-flop exactly when the data is changing. In fact, it is the same.  There is an arbitration flip-flop somewhere that decides. The FF becomes perfectly balanced, a metastable state, like a broom balanced vertically. While in a metastable state, a digital device has some interesting analog properties. Both Q and Q-Bar can be high (or low) for some undefined period of time, much longer than quoted settling times. Depending on the logic that follows, you may create a state that shouldn't ever exist.  In the PDP-11 case, I forgot the failure, but it was catastrophic. It didn't destroy the equipment, but crashed the bus. It was extremely rare, and required two weeks between incidences.  

This was exactly the case of the precision integrating A/D converter I witnessed.  A FF sampled the value of a zero-crossing comparator as the integrator was near zero.  It didn't matter whether the comparator was a 1 or a 0, the algorithm would work either way.  But occasionally, once every few hours, the flip-flop sampled the comparator right as it was transitioning. The FF would momentarily hang. Q and Q-Bar would both go to 1 for a few nanoseconds, and then settle.  Boolean logic dictates that a 0->1 transition only occurs if the state is changing from 0 to 1, but there were cases when there would be a 0 before and after the clock, but a brief momentary 1.  Exactly the same as the PDP-11 arbitration problem. This caused two different logic paths afterwards to treat the comparator value differently.

Though it is not possible to bring the probability of a metastable issue in asynchronous circuits to 0, it is possible to bring it very very close (double clocking, for instance). It is also possible to inspect the logic that follows to make the consequences less severe. 

Two people walking down a hallway face to face.  Two cars entering an intersection at the same time.  We've all seen it. There is a delay in the logic of deciding who goes first. Theoretically, it is possible to starve to death if placed equal-distance between two pizzas.  That one I have NOT witnessed.

 

 

 

 

MeasurementBlues
User Rank
Blogger
Re: PDP-11
MeasurementBlues   7/29/2013 1:10:43 PM
NO RATINGS
>Two cars entering an intersection at the same time.

In Boston, we chall that a game of chicken. The more aggressive driver, usually the one with the older car, usually wins.

Larry Desjardin
User Rank
Blogger
Re: PDP-11
Larry Desjardin   7/29/2013 1:25:25 PM
NO RATINGS
if car A goes through the intersection first, no problem.  If car B goes first, no problem. The ties are problematic. 

My observation in Boston is that the car with the least value has the advantage.

MeasurementBlues
User Rank
Blogger
Re: PDP-11
MeasurementBlues   7/29/2013 1:31:36 PM
NO RATINGS
>My observation in Boston is that the car with the least value has the advantage.

Generally true.

kfield
User Rank
Blogger
Re: PDP-11
kfield   7/30/2013 2:15:02 PM
NO RATINGS
@LarryDesjardin

I couldn't agree more. When I first moved to Boston before the completion of the Big Dig, it was horrendous to enter the tunnel to or from the airport, where at least six to eight lanes of traffic necked down to two lanes. I noticed a late-model Mercedes and some old junker vying to occupy the same space at the same time with neither giving an inch. I was slack-jawed to see the beater literally peel the side trim off the Mercedes.

betajet
User Rank
CEO
Mercedes abuse
betajet   8/1/2013 2:08:46 PM
NO RATINGS
For the "best abuse of a Mercedes in a motion picture", I heartily recommend The Driver (Walter Hill, 1978) starring Ryan O'Neal as the title character, who is the best get-away driver in the business, and Bruce Dern as the detective obsessed with catching him.


See it on the biggest wide screen you can find.

Tom Murphy
User Rank
Blogger
Re: PDP-11
Tom Murphy   7/29/2013 2:23:26 PM
NO RATINGS
Good observation about the cars in an intersection, Martin. I've also noticed that high-priced sports cars will often yield before low-cost beaters, and that they go out of their way not to park too close other cars in parking lots. 

rjs20
User Rank
Rookie
Debugging book
rjs20   7/29/2013 11:28:31 AM
NO RATINGS
A good start to learn general troubleshooting is to read "Debugging" by David J. Agans (ISBN 0-8144-7457-8).

For electronics, "Troubleshooting Analog Circuits" by Robert A. Pease (ISBN 0-7506-9184-0) covers analog circuit issues, but many "digital" problems are "analog" in cause.

Additional: Some "questions" (paraphrasing from Pease's book).

Did it ever work right? How do you know it's not working? When did it stop working? What else happened at the same time? Milligan's Law: "When you are taking data, if you see something funny, Record Amount of Funny."

Schultz's Rule: "Fix what you know is broken."

From the companion site for Agans' book:  http://www.debuggingrules.com/debuggingrules.jpg

 

Caleb Kraft
User Rank
Blogger
Re: Debugging book
Caleb Kraft   7/29/2013 12:58:22 PM
NO RATINGS
I've heard good things about Pease's book. I'll have to check that one out. People always ask me this question all the time and I'd love a good document to point them to. 

sdbowen
User Rank
Rookie
Troubleshooting basics
sdbowen   7/29/2013 12:44:19 PM
NO RATINGS
The author is correct that troubleshooting is an art.

As far as skills for a good troubleshooter for electronic circuits
  • Understanding there may be a mistake in the circuit design
  • Understanding there may be a mistake during circuit assembly
  • Debugging individual circuit segments
  • Knowing the problem may be in the components and not the circuit design
  • Attacking the problem from different angles
  • Experience knowing when your knowledge isn't enough and to call in help
  • Not being afraid to start over from scratch

I am a manufacturing engineer and not a circuit designer but have plenty of experience in electronics.  Solving a difficult problem is about how knowledge and experience are used to create a solution.  Sometimes troubleshooting is fun.  The joy in solving the problem can make having the problem worth it.

When I troubleshoot, I am never afraid to make a mistake or go the wrong direction.  Learning what doesn't works is just as good as learning what does.

rich.pell
User Rank
Blogger
Re: Troubleshooting basics
rich.pell   7/29/2013 10:01:31 PM
NO RATINGS
"Sometimes troubleshooting is fun."

That's true, but maybe more so if it doesn't involve one's own design. :)

MeasurementBlues
User Rank
Blogger
Ace reliever
MeasurementBlues   7/29/2013 1:13:19 PM
NO RATINGS
In baseball, if a relief pitcher makes a mistake, he is remembered. If not, he is forgotten.

I still remember the relief pitcher who gave up the hit that went through Bill Buckner's legs in 1986.

Max The Magnificent
User Rank
Blogger
"I would take a guess"
Max The Magnificent   7/30/2013 11:23:31 AM
NO RATINGS
I was once being sort of interviewed for a job. I say "sort of" because the interview was taking place in a pub over a pint or three of beer, but we digress...

One of the questions I was asked was "So we have a new system... we power it up... and it doesn't work as expected... how would you go about debugging it?"

I replied "I'd take a guess." I then went on to explain that everything depended on the circumstances and the particular system in question, but that my typical approach would be to observe what the system was doing -- e.g., what responses was it putting out -- plus any other "input" such as prior experiance with similar systems or prior experiance with systems performing similar actions -- and use my intuition to focus on what I thought might be the problem area.

If I was right, then I could hone in on the problem area really quickly and start the process of identifying the exact problem and coming up with a fix. If I was wrong, then I wouldn't have lost too much time (plus I would already gave gleaned some useful information as to what the problem was "not"), and I would commence a more exhaustive debugging process taking things step-by-step until I isolated the problem.

All I can say is that I got the job.

Tom Murphy
User Rank
Blogger
Re: "I would take a guess"
Tom Murphy   7/30/2013 2:18:05 PM
NO RATINGS
Max: And I think they were prudent to hire you, Max.  The more scientific method of finding the problem would be to treat each possible problem equally.  But an educated guess is the place to start first, and it is what we all do every day in every problem we face.   We often make mistakes, but that adds to the cumulative knowledge, doesn't it?

There's a business school standard exercise:  You're a CEO who needs to boost revenue but faces a tough choice.
A) You start a high-risk project that could yield enormous rewards.

B) You could instead expand existing lines of business, confident they'll add some revenue, though not nearly as much as you need.

C) You ask your managers for further study.

Wanna guess?

Max The Magnificent
User Rank
Blogger
Re: "I would take a guess"
Max The Magnificent   7/30/2013 2:28:35 PM
NO RATINGS
@Tom: Wanna guess?

Do you mean guess what the "right" answer is, or what the business school says it is, or...

I'm rubbish at the business side of things. I would say that if we already know (B) won't make enough money ... and we also know that managers waffle and cover their rosy cheeks -- then I would go for (A).

But that's easy for me to say when I don't have people's jobs/lives hanging in the ballance.

 

I guess another alternative would be to fire all of the managers :-)

Tom Murphy
User Rank
Blogger
Re: "I would take a guess"
Tom Murphy   7/30/2013 2:32:39 PM
NO RATINGS
Thanks Max.  While we wait for a couple of other guesses, would you like to explain why you picked A?

Max The Magnificent
User Rank
Blogger
Re: "I would take a guess"
Max The Magnificent   7/30/2013 2:56:17 PM
NO RATINGS
@Tom: ...would you like to explain why you picked A?

You should know by now that the problem is getting me to STOP talking :-)

Once again, please remember that I have no background in business whatsoever -- I prefer the world of digital logic :-)

The problem started by saying "You're a CEO who needs to boost revenue" -- when we combine this with the comment in (B) that says "they'll add some revenue, though not nearly as much as you need" I take thsi to mean that I REALLY need to boost revenue.

Option (C) says "You ask your managers for further study." To me this implies that they've already done some study -- hence the fact you knwo (B) won't generate enough additional revenue -- will "further study" change anything? To me that's just a way to kick the can down the road.

Someone has to make the tough choices, and as a hypothetical CEO with nothing to lose I chose (A) :-)

 

 

 

Tom Murphy
User Rank
Blogger
Re: "I would take a guess"
Tom Murphy   7/30/2013 3:41:05 PM
NO RATINGS
OK, spoiler alert: I'm going to spill the beans here....

...You are correct, Max, for that very logical answer. The explanation usually given in biz schools is this: Option A represents risk and potential reward. Option B leads to failure, so that's not a good option. And Option C also leads to failure. So Option A is the only one that might lead to success. If you try it and it fails, then you can still try something else. So it's the only viable course.  As you say: someone's gotta make the tough calls.

Max The Magnificent
User Rank
Blogger
Re: "I would take a guess"
Max The Magnificent   7/30/2013 3:47:50 PM
NO RATINGS
@Tom: You are correct, Max, for that very logical answer.

Well, color me surprised (LOL) ... I was totally expecting "You are wrong max, for that incredibly badly thought out answer"

Maybe I should take the rest of the day off to celebrate :-)

betajet
User Rank
CEO
Re: "I would take a guess"
betajet   8/1/2013 2:18:23 PM
NO RATINGS
D) You stop all development and fire all your engineers, greatly reducing costs and improving the quarter's profitability.  Wall Street rewards you with a quick up-tick in stock price.  You collect your incentive bonus tied to the stock price, cash in your stock options, and exit -- stage left -- leaving others to deal with the empty shell of a formerly great company.

Tom Murphy
User Rank
Blogger
Re: "I would take a guess"
Tom Murphy   8/1/2013 2:27:44 PM
NO RATINGS
Betajet: You've missed your calling. You belong on Wall Street! 

No doubt, there is incredible pressure on CEOs to boost short-term profit, which tends to lift their stock price.  I try to keep that in mind when I see companies like  Yahoo and Apple struggling to regain their footing in a very difficult market  as their stock price plummets.

MeasurementBlues
User Rank
Blogger
Re: "I would take a guess"
MeasurementBlues   8/1/2013 6:17:06 PM
NO RATINGS
Sounds about right. the great American way.

D) You stop all development and fire all your engineers, greatly reducing costs and improving the quarter's profitability.  Wall Street rewards you with a quick up-tick in stock price.  You collect your incentive bonus tied to the stock price, cash in your stock options, and exit -- stage left -- leaving others to deal with the empty shell of a formerly great company.

Larry Desjardin
User Rank
Blogger
Re: "I would take a guess"
Larry Desjardin   7/31/2013 12:58:20 AM
NO RATINGS
Hey Max!

"I would take a guess" is a great answer. By definition, nobody knows the root cause of the problem. Taking a guess is a much better next step than NOT taking a guess. By phrasing it as a "guess" you are showing that you are open to it not being correct, and taking the next guess, if needed. 

I'm glad that you got the job. Other applicants probably had blank stares. 

Larry

Max The Magnificent
User Rank
Blogger
Re: "I would take a guess"
Max The Magnificent   7/31/2013 10:56:17 AM
NO RATINGS
@Larry: I'm glad that you got the job.

Me too -- it was one of the best things that could have happened. After I left university I got a job at International Computers Limited (ICL) -- I learned a lot there, and my mother could see a long term career for me (in her mind ending with me as CEO) -- but after a year two managers left to form their own start-up company -- and this was the interview I was talking about.

I was number 6 in -- I arrived the day after the desks and chairs, so the other 5 said I was a lucky b*****d person -- I always sort of thought of myself as a "junior member" because there were others before me ... I didn't really pay much attention to the way in which the company was growing .. when I left I think there were 100+ people there and someone said "you can't leave, you're the old man of the company" ... it wa sonlt then that I realized that to the 95+ who came after me I was pretty much part of the establishment

It's funny how we see ourselves and how others see us :-)

PS On re-reading the above I remember what I meant to say -- when my mother heard I was leaving ICL to join a small startup she was disgruntled to say the least and fought it tooth and nail .... now she says it was the best thing she ever advised me to do LOL

MeasurementBlues
User Rank
Blogger
Re: "I would take a guess"
MeasurementBlues   8/1/2013 6:19:06 PM
NO RATINGS
"you are showing that you are open to it not being correct,"

Hello Larry, remember me?

In some companies, the quote above is interpreted as a sign of weakness, to be avoided.

Greybeard1
User Rank
Rookie
Learning to troubleshoot
Greybeard1   8/1/2013 1:25:32 PM
NO RATINGS
From what I've seen, engineers aren't trained to troublshoot, we're trained to design. 

While obtaining my BSEE, I remember being the 'whiz kid' in engineering labs. My labs were done first, usually worked, and I was willing to help others get theirs going.  Why could I do that?  Because I learned troubleshooting as an electronics tech in the Coast Guard, and honed it on remote stations where replacement parts could be days away.   The longer it took, the more risk to the public (no pressure at all...)It doesn't apply as well in production/design, but learning how to diagnose and repair a problem when you have limited time and resources makes you good at it.

If you want to learn troubleshooting - hang out with field repair techs, especially in-house at small repair shops.  Hospital Biomed techs are especially good at it; diagnosing and repairing an XRay machine with the Radiologist breathing down your neck and patients backing up is very much trial by fire.

 

MeasurementBlues
User Rank
Blogger
Depends on the manager
MeasurementBlues   8/1/2013 6:22:55 PM
NO RATINGS
Some managers see troubleshooters the the people you keep around who saves the day. To others, they think if you need to troubleshoot, you messed up in the first place and that's not acceptable.

Mohammed Hamed
User Rank
Rookie
Tools
Mohammed Hamed   8/5/2013 3:09:41 PM
NO RATINGS
Since it hasn't been mentioned here I'll mention it. Using the right "TOOLS" for the job and knowing how to use them. The difference can be hours, days, or months of troubleshooting effort.



Flash Poll
EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Rishabh N. Mahajani, High School Senior and Future Engineer

Future Engineers: Donít 'Trip Up' on Your College Road Trip
Rishabh N. Mahajani, High School Senior and Future Engineer
Post a comment
A future engineer shares his impressions of a recent tour of top schools and offers advice on making the most of the time-honored tradition of the college road trip.

Max Maxfield

Juggling a Cornucopia of Projects
Max Maxfield
2 comments
I feel like I'm juggling a lot of hobby projects at the moment. The problem is that I can't juggle. Actually, that's not strictly true -- I can juggle ten fine china dinner plates, but ...

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
28 comments
I'm a big proponent of engineers learning financial basics. Why? Because engineers are making decisions all the time, in multiple ways. Having a good financial understanding guides these ...

Karen Field

July Cartoon Caption Contest: Let's Talk Some Trash
Karen Field
127 comments
Steve Jobs allegedly got his start by dumpster diving with the Computer Club at Homestead High in the early 1970s.

Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)