When I first started writing software in machine (assembly) language, I found that other folks had developed some really nice tools to help debug programs at that level. One of my favorite tools is the “breakpoint” which allows stopping execution and dumping out diagnostic information to a display terminal. (Yes, I am old enough that some of the “display terminals” were really printing terminals.)
Once the program-under-development reached the breakpoint, a debug program took control and allowed the person at the console to examine internal registers, memory values, and I/O device states. It was typical to discover that some variable (a counter, a pointer, an array, etc.) contained an unexpected value. We could then set a breakpoint at an earlier place in the code and start single-stepping from an arbitrary point to determine why that variable contained an unexpected value.
It often became quickly obvious where the coding mistake had occurred. Sometimes the failure cause was much more hidden. For example, if an interrupt service routine was accidentally overwriting a shared value, one could not see the effect unless that interrupt happened (at the appropriate time) during the debug process.
Most debugging programs included a command which allowed you to substitute for any instruction a breakpoint instruction in RAM (random access memory—in other words, writeable memory space). However, this meant that you could not use the debugger to insert breakpoints into Read-Only-Memory.
It was typical for software developers to create their own tools to expand the breakpoint capabilities of their favorite debugger. The more we could see, the more we could fix. At some point, we often would discover that adding too many diagnostic output messages interfered with the failure mechanism. This could mean that the system would fail under normal circumstances, but might work fine in debug mode.
A hardware corollary is the circuit which fails under normal operation, but never fails when an oscilloscope is connected. The old joke was that we just needed to ship an oscilloscope with every unit.
In the case of such a hardware failure, we typically could identify that the oscilloscope connection was adding some small capacitance or leakage resistance that changed the circuit behavior. This often was enough of a clue to help identify the hardware design failure.
Software failures that exhibited extreme sensitivity to debugging processes could be probed with low-impact operations such as writing an instantaneous value to an arbitrary unused I/O location. A logic analyzer or some additional debug hardware could be added to the system to help capture the extra debug information without affecting the real-time operation (or affecting it only a tiny amount).
In life we often encounter breakpoints that have nothing to do with computers. Major events such as marriage, divorce, births of children, and death (of other folks) can halt our normal operation and cause us to closely examine our internal and external state of operation. At the risk of stating the obvious, our own death represents a significant breakpoint.
Even minor exceptions can lead to extensive revamping of our internal codes and behaviors.
Breakpoints in life (or electronics) are different from reaching the breaking point of materials or systems. I vaguely recall my mechanical engineering student acquaintances talking about an Elementary Strength of Materials class. This was where most of them first learned to not build houses, bridges, cars, or airplanes out of bubble-gum and bailing wire.
All materials have breaking points related to the operating and mechanical stresses applied to them. Some of these stresses are part of normal operation and some stresses are created by environmental conditions having nothing to do with normal operation or a normal environment. It is critical that we design components and systems which have some resilience to both normal and abnormal conditions.
Likewise, I believe you should take advantage of breakpoints to carefully examine your personal operating state. We all depend on each other to keep this machine of life in proper working condition.