Saturday, June 24, 2006

Long Programming Short

I have often wanted to equip myself to do programming in short bursts. I often think I can accomplish this in the check out line at the grocery store, or while commuting (voice recorder for driving, or handheld device for bus/train/carpool). I often think, "if only I could use all this dead time to get something done." Here's the problem: that dead time is dead because you don't have something to program that is small enough to fit a unit of it into that time, and still interesting enough to be worth doing.

Sure, I can write "Hello, World" applications all day at the 7-11, but I can't really implement an object relational mapper, or a compiler while waiting for my meal at Del Taco. Interesting problems are by definition hard. Anything that could be done in the "off time" of some other activity has already been done in every programming language, most of which you can just download from the internet for free, because the authors know it only took them 20 minutes to do.

How can we combat this problem and still end up using those lost minutes productively? One thought is parallelism. If you can break your huge task into millions of little tiny (different) tasks then you could conceivably just do a single miniscule task while you wait for your quadruple espresso. You have to maintain a list of the tasks, unify the code somewhere, and make the entry reasonable enough that you can do it anywhere.

Another idea is to use an iterative approach. Just do one small change. Refactor a single line of code, change an error message, rename a function in your program, put a copyright header on yet another file, adjust your make file, write a single test within a larger unit test framework, just do something. Squeeze in commenting the "why" of a function or portion of a function while the $3.50 gas flows from the pump to your eternally thirsty gas tank.

Can it be done? I'm not sure, but it's worth a college try at least.

0 Comments:

Post a Comment

<< Home