Once upon a time, I was programming something and it wasn't doing what I wanted and I was turning into a ball of frustration. Adam's suggestion was to "Stop writing bugs!" So I stopped telling the computer to do things I didn't really want it to do, and I lived happily ever after. JUST KIDDING!
Anyway, two things:
Sometimes I have to slow down and try to be more thoughtful about what I'm programming. Frantic flailing about and guessing and testing hypotheses (especially multiple hypotheses at once) is where trouble comes from. I try to avoid this. And to notice if I'm flailing about and let myself stop and try a new approach. If I don't understand how something works, I (usually) test it out somewhere else or read about it more. Essentially, I should know what the code I'm writing will do.
I had a bad habit of writing PHP code with no debugging info available and no idea where the error logs were. Make some edit and suddenly the whole page is blank. I would put on my "not gonna write bugs!" hat and try to be careful, but I was wasting my own time not just having the logs there to tell me when I was missing a semi-colon or something trivial.
There are lots of other tools for different situations. Core files and gdb are sort of my friends these days. Chrome's developer tools. The debugger version of Flash. Adam claims packet sniffers are great, but also under-appreciated, and wants me to mention strace as well.
In conclusion, learn how to make your computer divulge its secrets.
 |
| I don't recommend telling your girlfriend to simply stop writing bugs, but in this situation, I was like, "Huh. That's pretty philosophical and vague, but I'll give it a try." It worked, in that I got that code sorted out. |
Agency
You have control here. The bugs aren't coming from the computer or the outside world (except for the original computer bug); they're coming from the programmer.Sometimes I have to slow down and try to be more thoughtful about what I'm programming. Frantic flailing about and guessing and testing hypotheses (especially multiple hypotheses at once) is where trouble comes from. I try to avoid this. And to notice if I'm flailing about and let myself stop and try a new approach. If I don't understand how something works, I (usually) test it out somewhere else or read about it more. Essentially, I should know what the code I'm writing will do.
Getting the truth out of the computer
These are recent ideas from Adam expanding on the "stop writing bugs" philosophy. The computer will still do things you don't expect or don't understand. But it usually has a reason, and there are tools to find out those reasons.I had a bad habit of writing PHP code with no debugging info available and no idea where the error logs were. Make some edit and suddenly the whole page is blank. I would put on my "not gonna write bugs!" hat and try to be careful, but I was wasting my own time not just having the logs there to tell me when I was missing a semi-colon or something trivial.
There are lots of other tools for different situations. Core files and gdb are sort of my friends these days. Chrome's developer tools. The debugger version of Flash. Adam claims packet sniffers are great, but also under-appreciated, and wants me to mention strace as well.
In conclusion, learn how to make your computer divulge its secrets.
Comments
Post a Comment