I think that we experienced guys need to have more empathy with the new
folks. Remember, we were new once, too. Remember how hard it was?

That's it.

--Bob

At 12:22 PM 7/8/2003 -0500, you wrote:
> > >
> > > I agree that 'voodoo programming' does not help, and I have no time
> > > for the folk who when faced with a plain simple programming error
> > > resort to debug techniques such as "lets try booting from my lucky
> > > disk", but nevertheless, you have to come up with some
> > theories before
> > > you debug, otherwise it is pure guesswork!
> >
> > No, it isn't.  Not knowing what's wrong does not imply
> > guesswork.  Often once a system is basically working, you can
> > look at a symptom and be quite sure what's wrong.  Those are
> > usually the "Oh, yeah, I forgot about that" bugs.
> >
>
>When you don't have a depth of understanding, then guesswork is all you
>have.  It has a low payoff, but what else can you do?
>
> > However when you first try to get something to work the
> > "system doesn't respond" symptom isn't very useful in
> > narrowing down on the problem. Aside from checking a few
> > obvious things (power on?, MCLR released?, oscillator
> > running? ect) it is better to keep an open mind and *not*
> > assume you know why it's doing what it's doing.  That allows
> > you the mindset to methodically check everything instead of
> > jumping around spot checking one hairbrain guess after another.
> >
>
>I agree with you on this point.  I think people often want to blame the
>hardware (the pic microcode has a bug in it) instead of their own
>mistakes.
>
> > I've also noticed, especially with inexperienced programmers,
> > that their guesses are usually wrong and far fetched.
>
>That's what makes them inexperienced.  If you know immediately what is
>wrong, then you are experienced.
>
> > Just
> > check the archives of this list for lots of incredibly stupid
> > guesses as to why someone's program doesn't work.  It seems
> > we had several in just the last few days. First some bozo was
> > trying to tell us the EEPROM read back randomly (turned out
> > to be bank switching, big surprise), then someone tried to
> > blame a hardware reset problem on software, and now we've got
> > some rocket scientist trying to tell us that two INCF FSR
> > don't produce the expected result.  In all these cases it
> > would have been much more productive NOT to waste time on
> > wildass guesses and instead spend the effort carefully and
> > methodically figuring out what IS wrong instead.
> >
>
>You know, if it ticks you off so much responding to these "rocket
>scientists" and "bozos," then why don't you just ignore them?
>Personally, I am grateful for any correction to my understanding of how
>the PIC works.  Essentially, "you think it works that way, but it
>doesn't"  People build up mental models continually, and as they become
>refined they learn and become "experienced," which gives them the right
>to laugh at other people's struggles.
>
>
>
>Alex
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.

---------------
NOTICE

1. This account can accept email & attachments up to 10M in size.
2. Federal Monitors: At request of client, some attachments are encrypted.
Please DO NOT delay traffic; please reply with credentials for password.
--------------

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.