AVR Freaks

They are surprised by their understanding of C / C++.

Or better: They are surprised by their misunderstanding of C / C++.

They are surprised by the fact that C / C++ just describes an abstract machine, and that each one of the infinitely many possible implementations of that abstract machine has infinitely many ways to translate a specific function.

When you are going from the concrete to the abstract, this means to throw away information.  When you model a tennis ball as a perfect sphere of a specific radius with a specific mass density and moment of interta, then you are forgetting many things about that concrete tennis ball.  When you want to go back from the abstract to the concrete, you have unimaginably many degrees of freedom to design your tennis ball, and which you MUST add to get a real tennis ball.  Likewise, when a compiler transforms a source describing the actions of an abstract machine back to a concrete binary, the compiler will (and must) pop that "lost information" out of thin air.  A compiler is guided by switches and metrics like costs, but still it has to map the abstract to the concrete.

And it is the result of abusing tools like debuggers and simulators.

Such tools can help to better understand how the silicon works, and what assembler is about, maybe even get a better understanding how a compiler as concrete piece of software works, yes. But after all, a debugger is a de-bugger, a tool to find bugs.  If a code has a bug, then you know that the source has a bug (or sometimes the tool has a bug).  But if a code works as expected, then this is no proof whatsoever that the source is correct.

Sometimes I have the impression people regard debuggers and simulators as design tools to develop software, not as a last resort to locate a bug (and often incorrectly infer from as-expected binary that the input is correct, after tweaking the source until everything looks as expected).

 As Lance Taylor put it:
 

Michelangelo reportedly said that he could see a statue in a block of marble, and that his goal as a sculptor was to carve away everything which wasn't part of the statue. Some programmers appear to similarly believe that programming means starting with a block of code, and carving away everything which isn't part of the program. This is also known as programming by debugging. It's a bad idea. Don't do it.

And people are permanently tought to use debuggers or simulators as design tools.  If someone asks "what does this piece of C code do" then a frequent answer is NOT to explain the code but just a recommendation to "pipe that stuff through a simulator and stare at the result".

People are tough to stare ar binary code, they are tought to stare at testing. (A test runs binary code after all).  Testing in inevitable in a development process, but focusing on testing is often a symptom that other means like reviewing, well documentation comments, having well trained staff or avoid bad environment (like stress, task switching, dead-lines etc.) are neglected.  Tests have the problem that they can easily be measured. "we have 100000 tests" and everybody is impressed. Tests can be generated and their number be increaded like mad. Something you cannot do with knowledgable reviewers, where all to often their sheer numbers serves to compensate their lack of deep understanding.

If I was allowed to pick just one favourite sentence out of Georg-Johanns excellent post it would be:

That summarizes the situation brilliantly.

Alas, telling that to a frustrated beginner of "step-n-trace debugging" will probably just have them answer "abstract machine??". I just want the code that executes do exactly what I wrote in the source C code. But of-course I want optimization too..".

I can understand a certain instance, such as that and other bitstream encoding.  But is a single case with simple decisions, right?  Not "multiple fairly extensive code branches".