I’ve known for quite some time that I suffer from a habit that is common to many programmers. When I finish a challenging part of a program - after having spent an awful lot of time looking at incorrect output of one form or another - I find myself so surprised that things are working that I then spend a silly amount of time rerunning the program and admiring the correct output.
I’m so glad I’m not alone. Doesn’t make me normal. Just … not alone.
So, the introductory part of the writeup is very fluid and strongly struck a chord with me. However, the actual technique described here was not so clear to me. The core seems to be this:
Therefore what I found myself doing was continually leaving some small part of my system in such a state that it needed to be debugged.
I write scientific software and there are places if you know you have bugs, you gotta fix them right away. And usually in such places, TDD is the way to go - your code implements an algorithm, the algorithms is written down first, it’s characteristics and edge cases enumerated, tests written, then code written and inspected closely until the test suite passes. (oddly, I’ve also had several instances where it turned out my tests were wrong. That is, while implementing the algorithm I understood it better and/or I made a logical error in setting up the test)
Any how, the places where I can let “bugs” get through is more in the UI or feature part, where I can leave out some safeties or some features - basically some user input can crash the program, or some use cases are not handled. That is where I can leave things and move forward.
But I definitely agree with the OCD part, where I just can’t go to sleep with a bug in my code. I’ve gotten better at it though, and am slowly training myself to sleep on it, which often leads to faster bug resolution.
I’m so glad I’m not alone. Doesn’t make me normal. Just … not alone.
So, the introductory part of the writeup is very fluid and strongly struck a chord with me. However, the actual technique described here was not so clear to me. The core seems to be this:
I write scientific software and there are places if you know you have bugs, you gotta fix them right away. And usually in such places, TDD is the way to go - your code implements an algorithm, the algorithms is written down first, it’s characteristics and edge cases enumerated, tests written, then code written and inspected closely until the test suite passes. (oddly, I’ve also had several instances where it turned out my tests were wrong. That is, while implementing the algorithm I understood it better and/or I made a logical error in setting up the test)
Any how, the places where I can let “bugs” get through is more in the UI or feature part, where I can leave out some safeties or some features - basically some user input can crash the program, or some use cases are not handled. That is where I can leave things and move forward.
But I definitely agree with the OCD part, where I just can’t go to sleep with a bug in my code. I’ve gotten better at it though, and am slowly training myself to sleep on it, which often leads to faster bug resolution.