The Roadie's Rules to troubleshoot ANYTHING

[The_Roadie]

To test out the new PDF embedding feature, here's a link to something I wrote up a couple of years ago. Styled on Bob Parson's "16 Rules to Live By" (founder of Parsons Technology and GoDaddy). It's a distilled collection of my top 16 concepts for system troubleshooters, and has stood me well in my 38 year career as an electrical engineer and test system architect and diagnostician.

I want copies handed out at my funeral.

[PDF]http://www.roadie.org/bill%20carton%27s%2016%20rules%20.pdf[/PDF]

 

[Blckshdw]

PDF embedding huh? That's a pretty good idea, never thought of something like that, but it will sure come in handy.

 

[barron03]

 

[djthumper]

Very similar to how I do my work.

 

[06Envoy]

Words to live by indeed!

 

[Canadian Mike]

roadie.org

 

[Mark20]

Good info. Something I ask myself a lot when trying to figure out why the system won't work (also an electrical engineer though I specialize in embedded software),

"Now what is this telling me?"​

 

[The_Roadie]

"Now what is this telling me?"​

Excellent question to ponder, as long as you also remember Greg House's advice "everybody lies". If you ask an imprecise question (monitor the wrong signal, the hardware designer fails to install a pull-up on a floating line, have a timing race condition, etc.) the answer may lead you to the wrong fork in the troubleshooting flowchart. I do mostly hardware and user software design, but I'm always putting in hooks to let the embedded folks send me signals that we only use for troubleshooting. Otherwise you're reduced to veterinary medicine, where the patient can't answer questions other than "does that hurt" by biting you.