The value of taking breaks

One of the things I keep re-discovering when working on little software projects, is the value of thinking about stuff away from the computer.

Today, for example. I spent two hours mucking around @thecoffeeshop, debugging a Javascript file on the CR-48. Mostly problem discovery mixed-in with trying to come up with an answer with code. It was confounding, because each of my attempts to fix would not work. I was also fixing little things along the way, and many of my ancillary thoughts were related to the act of coding and using the computer.

It started to snow, and got very cold, so I gave up and walked back home.

During that time, about 20 minutes, I thought lightly about the problem (solution analysis) along with stuff not related to the programming issue, such as my schedule for the rest of the day, the weather, etc. When I got back home, I setup my dev enviroment, and basically fixed the problem in 5 minutes.

What does all this say?  I think a few things can be learned from my little 'case study':

Fixing little problems is mostly what development is about. Particularly informal, incremental development - but this just as easily could apply to planned development. There are always going to be technical obstacles in implementing, and your challenge is to overcome each one and close-in on a finished product.

For each of these little obstacles there are little phases you take to solve them.

1. Research - find out what you don't know. This can take a little while sometimes. For this particular problem, I had to do some research on bit-mapping and codepages the night before. Little bits of test code were written as proof-of-concept. The takeaway was not really a solution, but a realization of that I needed to  do more work, to satisfy certain dependencies in order to find a solution. Frustrating and messy.

2. Problem Discovery - Actually examining and testing existing code to discover what it wasn't doing. Frankly this was also messy. When I got tired of trying to analyze what was going on, I ended up doing code-housekeeping as a 'break' only to change things enough to the point I was not certain the environment was the same. I ended this phase feeling annoyed with myself.

3. Solution Analysis - Interestingly enough, away from the computer. I couldn't just impulsively follow hunches, doing research, testing code snippets or cleaning-up existing work. As a diversion my thoughts were interleaved with other totally unrelated matters for about 20 minutes. The takeaway from this was a feeling of being less frustrated, tangled. I also had a vague suspicion about what I had been doing wrong. Thoughts were bubbling-up naturally rather than being a kind of forced slavery that I often put my mind through when trying to solve something.

4. Trial Implementation - About 5 minutes to a solution (or at least substantial progress toward one.)  I did do minor layout housekeeping first to clarify the toilet-paper roll of code. I was also using better equipment and ate lunch while I was working. I rolled back to a previous version I knew was better quality, and resumed work from there.

I don't regard myself as a very good programmer. I have struggled with this fact for awhile. I take heart in criticism of co-workers who have said in the past I tend to make things too complicated. They are correct. I also take heart in the fact that almost every project I worked on was not entirely my work. Contributions of other people are ever-present. It helps to remember these humbling facts, because being open to a little self-criticism probably makes you more effective at what you do.