35% smaller, and 14% faster code!

Also, 'debuggability'; whose dictionary do you use?
none just tried to emphasize that I did, by no means, try, by 'debuggability' to indicate that I did not consider anything could not be debugged, but were referring to the ability to do efficient debugging (ICE).

Re cavalier manner ... typographical errors
I am 'redecorating' and thus having the keyboard in my lap. also, a person should be able to 'read through' a few errors, I would never expect a computer to do so.

Re "amateur - hobbyist" I have produced working systems (not flawless in all cases, but with very few flaws in all cases) for more years than I am willing to admit, let me just say, some were before the microcontroller even existed.

Erik

To consider their code so superior that debuggability should not be a concern is a typical attitude of mateurs and hobbyists"

Also, 'debuggability'; whose dictionary do you use?
none just tried to emphasize that I did, by no means, try, by 'debuggability' to indicate that I did not consider anything could not be debugged, but were referring to the ability to do efficient debugging (ICE).

Re cavalier manner ... typographical errors
I am 'redecorating' and thus having the keyboard in my lap. also, a person should be able to 'read through' a few errors, I would never expect a computer to do so.

Re "amateur - hobbyist" I have produced working systems (not flawless in all cases, but with very few flaws in all cases) for more years than I am willing to admit, let me just say, some were before the microcontroller even existed.

Erik

To consider their code so superior that debuggability should not be a concern is a typical attitude of mateurs and hobbyists"

"I have produced working systems (not flawless in all cases, but with very few flaws in all cases) for more years than I am willing to admit, let me just say, some were before the microcontroller even existed."

Likewise, but I prefer to be more rounded when it comes to saying what is best - There is no perfect 'one fits all' solution and I would have expected someone with your claimed experience to appreciate that fact. I do not, in general, see the requirement to use ICE or even consider it when initially developing code. If there is an awkward problem, then I get it out - Else I prefer to study the code.

End.

I do not, in general, see the requirement to use ICE or even consider it when initially developing code. If there is an awkward problem, then I get it out
and what are you going to do then if the optimizer has 'threaded' your code and you can not set a 'working' breakpoint.

1) there is no issue "when initially developing code", my sole point is optimizer 'threading' vs breakpoints
2) debugging what is not "an awkward problem" need no special measures
3) if your method is not so that "an awkward problem" can be debugged in a reasonable time, you will miss some deadlines.

Erik

I've seen too many well qualified graduates who insist on going straight for an ICE when they see a problem, rather than looking for logic errors in their code.

There's no real substitute for thinking and no excuse for laziness.

I've seen too many "well qualified" graduates who insist on going straight for an ICE when they see a problem, rather than looking for logic errors in their code.
you forgot the quotes. I have seen many that were "well qualified" as far as academia goes, but not in the real world.

There's no real substitute for thinking and no excuse for laziness.
I wholehardedly agree.

as to your first point, this is not ICE, but the scope. Many many moons ago, when scopes were slower, our best hardware guy and the undersigned 'universalist' started hunting a "once a day" hit. Although software was blamed (I had recoded the process to run 4 times faster) I had no doubt it was hardware. Finally we decided to use the "DNA scope" and looking through the schematic of a peripheral with as far as I remember ~400 TTL gates found a possible pulse that the scope could not see. We removed the possibility of that pulse and the unit worked. Approaching the original designer he stated "that can not happen" and pointed to typical values in the datasheet AAARGH!

now, as far as "going straight for an ICE", the ICE is never going to tell you what is wrong, but it can be very helpful in finding where to look. E.g. when 2 processors communicate (I am currently having 8 running in tandem) the ICE can tell you whether it is transmission or reception. My main 'beef' with those that are "going straight for an ICE" is not their debugging method, but those types often "insert a fix" instead of actually finding the root problem by "looking for logic errors in their code". I always stated that bugs should NEVER be fixed, they should be removed.

Erik