Debugging Techniques

 As a programmer there are many approaches to a take in solving a problem, I remember in my A-Level they talked about trace tables... A lot... I've used them now and then, but almost immediately machines were running so quickly as to make humanly computing any meaningful number of permutations near impossible... and we're talking only a 25Mhz machine.

Far more useful therefore was a decent watch value in a debugger, improved immeasurably by conditional break statements.

Even so there are always times when you need that holistic overview, my favourite approach for this is a huge wide whiteboard.  Many an hour have I spent around a whiteboard laying out the schemes of madmen and managers; the greatest compliment is then when finding that said folks have taken a cheeky photo and your whiteboard machinations appear in the manual.

But one of the best problem solving solutions is to share it, a problem shared can often become a problem halved; unfortunately not always for a programmer.  You see people are a creature of opinion and social status, this means you can often run into folks who believes their opinion is more valid than yours, which maybe so, but if their opinion means starting the whole problem over again it can often be more detrimental than asking for their help.  For help becoming opinion leads only to their being demons in the cupboard.

So what then?  Talk to one self?

And you know I think really rather that is one of the key approaches, talk to yourself.  Quite useful in the current pandemic too.

We have a term for this in Computer Circles, and we detract from the self by making our conversation focus on another object, such as a rubber duck... https://en.wikipedia.org/wiki/Rubber_duck_debugging

Or of course you can find your own devices....