In my teens, after long programming session, my brain simply refused to understand what I was looking at. These occasions often led me to try to fix bugs by ran

In my teens, after long programming session, my brain simply refused to understand what I was looking at. These occasions often led me to try to fix bugs by randomly changing the code. Some bugs were mere off by one errors, then I changed for loops to stop earlier, initialized pointers to NULL and early bail out of a function if a parameter was NULL, increased size of arrays... It worked more often than I'd like to admit. Reading the code later was utter incomprehensible and left a bitter taste. Eventually I stopped using such technique. It was better to leave to code crashing than having it working without knowing why. To this day I still see inexperienced C programmers making the same mistake. Such fixes are the kind of mess that will make something work on a computer just to crash in another OS or architecture. The funniest example of such a specimen I saw was a very interesting graph problem solved in C. It worked beautifully. The algorithm was elegant and low complexity but it was not general enough and some cases had to be specially handled. New special cases were discovered and the team had to resort to a few tests that started breaking when other cases were fixed. Bug appeared and were fixed randomly. A last case was fixed and then all the other previous important cases crashed. What to do? Valgrind to the rescue! After running the code on Valgrind, success! Not that it helped fix the bugs, there were lots if complaints, but it didn't crash. So, instead of fixing the bugs, the team decided that it was to be run only under Valgrind and everybody was happy.