Holding a program in one's head

"I suspect there is an issue with the actual input from the database. (Note: we're working with a test database that's sketchy in spots) What do you want me to work on? Do you want me to spend the time tracking down that error or do you want me to work on "X" (that should have been done three weeks previous)? Because I was thinking about "X" and my entire train of thought is derailed and now I'm trying to work on "X" and wondering what is wrong with that particular chunk of data."

I suppose for the non-programmer it sounds like I'm just being nasty over nothing, but that little panic attack over a minor error message cost me HOURS in trying to get back to the original program in my head so I could finish it. In fact, I actually had to go and FIX the error to get it the hell out so I could fully focus on what I needed to be doing.

Once I got there, around 1am, the code flowed like water and it's done save for minor debugging. I was in the zone enough that if my eyes hadn't been closing by themselves, I'dve finished that, too.

Management, I think, has a double edged sword to deal with. My immediate boss wants to let me do what I do because I am lucky enough to have the ability to put someone else's code in my head in the same way described in this blog entry. It means that I can go in and fix it and if there's a bug I know why it's doing it and I know just where to push on it and where it needs shoring up--in short, after a while, it's like I wrote it myself.

But he's also dealing with HIS boss, who is dealing with the bottom line, and his boss would probably have apoplexy if he saw me playing spider solitaire as I let the problem I'm addressing work itself into my brain, and would have NO idea what I was talking about if I said I needed to get the application "into my head".

Wonderful blog entry.

Not to mention all the work that happened after they bought Keyhole et al.

I used to be excited about unit tests because of the promise of being able to make bolder changes to the code with certain confidence. And I feel the practice of making my code more testable improved my design skills.

But I found they are a maintainability issue too. They increased the cost of making the type of changes that would require me to change the tests- and normally, changes that don't break interfaces don't worry me a lot even if I don't have tests. Also, relying on the tests for a sense of confidence made me lazier about trying to really understand why the code worked. In general, it put my head in the mode of seeing the trees rather than the forest. YMMV.

Nowadays I write the code as if I was going to unit test it, and then I don't write the tests. When I do, I don't make much of a point of keeping them around; I use them basically as shortcuts to poking around in the REPL while I debug something. I try to keep things simple enough that not much can go wrong, I try to make sure I really understand how and why it works, and I try out most representative use cases I can think about.

That's enough to keep my debugging time quite low. When I do have bugs, I treat them as learning experiences: I try to understand why it happened and what can I do so I don't get more of those.