Upvoted for your very precise articulation of what encountering a bug feels like. ;)
I find it interesting that this style of development seems very familiar to me … except for the bit about automated testing! (Bear with me.) I tend to work on small projects, and because of the way I’m wired (i.e. because I haven’t rewired myself out of it), when I’m working on something larger, I can’t really keep many pieces of it in my head at once. When I try to, bits which aren’t drawing my attention right now will fall out of my brain, and sometimes those bits were important. So I have to focus on small pieces at a time—I’ll add the minimum amount of code which should produce a new result, make sure it works, and repeat. The principle of this seems much like the principle behind TDD; I just never learned to write tests for my code.
Another comment about evaluation of tests reminds me of someone I know who’s working on a project which evaluates the location and frequency of logging statements in a piece of code. I find this a very cool meta tool. Who debugs the debuggers? (If I find out he’s got some public writing about this I’ll link it.)
I tend to work on small projects, and because of the way I’m wired (i.e. because I haven’t rewired myself out of it), when I’m working on something larger, I can’t really keep many pieces of it in my head at once. When I try to, bits which aren’t drawing my attention right now will fall out of my brain, and sometimes those bits were important. So I have to focus on small pieces at a time[...]
Ye hairy gods, do NOT attempt to rewire yourself out of this. :-)
I don’t know of any programmers who are able to productively hold very large chunks of implementation in their head at once. Writing in small pieces with frequent result checking is nearly always a good idea even if your result checking isn’t regressive or automated. You should be happy you started out with this habit instead of having to force yourself into it.
wnoise summed it up well. I’m very pleased to have the habit (and am occasionally confused by people who don’t do it). But it’s frustrating to have that mental limitation. It makes me feel a bit dumb when I’m talking to Real Actual Programmers. :)
Upvoted for your very precise articulation of what encountering a bug feels like. ;)
I find it interesting that this style of development seems very familiar to me … except for the bit about automated testing! (Bear with me.) I tend to work on small projects, and because of the way I’m wired (i.e. because I haven’t rewired myself out of it), when I’m working on something larger, I can’t really keep many pieces of it in my head at once. When I try to, bits which aren’t drawing my attention right now will fall out of my brain, and sometimes those bits were important. So I have to focus on small pieces at a time—I’ll add the minimum amount of code which should produce a new result, make sure it works, and repeat. The principle of this seems much like the principle behind TDD; I just never learned to write tests for my code.
Another comment about evaluation of tests reminds me of someone I know who’s working on a project which evaluates the location and frequency of logging statements in a piece of code. I find this a very cool meta tool. Who debugs the debuggers? (If I find out he’s got some public writing about this I’ll link it.)
Ye hairy gods, do NOT attempt to rewire yourself out of this. :-)
I don’t know of any programmers who are able to productively hold very large chunks of implementation in their head at once. Writing in small pieces with frequent result checking is nearly always a good idea even if your result checking isn’t regressive or automated. You should be happy you started out with this habit instead of having to force yourself into it.
wnoise summed it up well. I’m very pleased to have the habit (and am occasionally confused by people who don’t do it). But it’s frustrating to have that mental limitation. It makes me feel a bit dumb when I’m talking to Real Actual Programmers. :)
The habit is very good. The necessity of it is bad. Larger working memory is incredibly useful for a programmer.