timothyweber.org

My troubleshooting rules can really help focus on solving a problem, but maybe first you’d like to not solve the problem for a while.

What?

Well, let’s look at a common sequence of events in creative or constructional work of many kinds:

1. See a problem.
2. Figure out how to fix it.
3. Fix it.

That’s pretty instinctual. Can’t really do those out of order. And once you’ve seen the problem, there is often some amount of urgency to get to the fix.

But the next step, if you’re conscientious, is:

4.. read more...

These rules certainly apply to software of all kinds, and electrical engineering, but they are also basic enough to apply to interpersonal issues, group dynamics, etc.

1. Is it plugged in?
2. Is it turned on?
3. Is it working as designed?
4. What’s changed since it worked?
5. What don’t you know?
6. Who haven’t you talked to?
7. Poke it with a stick.
8. Simplify!

And a bonus rule:

0. Don’t solve it too soon!

Sometimes when troubleshooting, you look at the problem very closely as it exists now. But in many cases, you can look back at what things were like before the problem existed. What worked then, and what has changed since that time? read more...

If you’ve gotten this far in my troubleshooting rules, this is a tough problem. Maybe you can solve it…

… but maybe instead you can replace the situation with a simpler one that will be less prone to problems? read more...

Maybe you’ve been troubleshooting for a while on your own. Or maybe you’ve discussed the trouble with someone else, but not the right someone else. Who could you talk to? read more...

Sometimes you start by troubleshooting assuming something’s broken, when really it’s just not working the way you expected. Put another way, it’s “working as designed” - but you and the designer miscommunicated, or disagreed.

Some questions to ask: read more...

http://www.youtube.com/watch?v=1QR0RnFN2S4 For some reason, I’ve always wanted to build a robot with tracks, and I’ve lusted after the Tamiya tank tread kit at SparkFun. So, when I scored $40 of credit on their recent Free Day, I bought it and the relevant accessories. read more...

Since I made my first mod to the PICkit 2 applet source, Microchip completely rewrote the applet. They use .NET, which I consider to be pretty much a virus, but I was considering getting all the MS development tools installed and getting up to speed with C# to work with it.

But then I realized that it would be simple to just automate the existing applet with an external program, and that would mean I wouldn’t have any changes to integrate into the Microchip source (as well as not having the dreaded MS tools installed). read more...

My PrayBot project last year needed a “solar engine,” and the quickest thing I could come up with was based on a PIC instead of the more usual BEAM-style solutions. This year I wanted something more efficient. But it still ended up with a PIC, and it’s much more efficient than any of the BEAM designs I’ve tried. read more...

While troubleshooting, another embarrassing discovery is that the thing in question isn’t working because you didn’t turn it on. This rule could come first, as in some sense it’s more basic than Rule #1, but for the simple AC-powered appliance, you have to plug it in before you can turn it on, so I list it second.

Again, there are lots more useful ways to think about whether you’ve turned something on. For instance: read more...