> so ironically you have to slow down and really get to know how to do programming very carefully, and then scale that up so that you can react really quickly later (with something like binary search). this is a useful thing to practice in some ways.
Any tips on how to practice this? I have been slowly discovering, on my own, ways to write code so that when bugs appear it is apparent which portion of code it appeared in. This can be as simple as logging often or as complicated as trying to predict when I might be doing something wrong and put a funky error message in a place I don't understand so when a bug does happen I can go to, or rule out, that section of code. Any tips?
Good, stringent mentors (esp., good, rigorous code reviews) are key.
Theoretically, depending on which language you choose, you should be able to rewrite a bit of code until there is literally not a single character that you could improve to make it clearer or more efficient.
It's good practice to do this -- eventually it becomes habitual. However, that doesn't save one from other people's code.
But yeah, there are certain virtuous cycles that work to your advantage if you take the extra time to try to improve even the most basic code (save one line here; make one idiom clearer, etc.) -- cascades over time...
My primary way of ascertaining how bug-free my code is, and the way I've never seen anyone mention, is by feel. Doesn't anyone else roughly know which code is likely to cause bugs and which isn't? Whenever I write some code without thinking it through or take my time, I know it's going to lead to bugs, even if it's very simple.
On the other hand, I have code I wrote that I trust completely. It turns out later that these metrics are, indeed, accurate. Does anyone else get this?
Any tips on how to practice this? I have been slowly discovering, on my own, ways to write code so that when bugs appear it is apparent which portion of code it appeared in. This can be as simple as logging often or as complicated as trying to predict when I might be doing something wrong and put a funky error message in a place I don't understand so when a bug does happen I can go to, or rule out, that section of code. Any tips?