N.A.D.D. and A Spindle of Prototypes

Many times in development we get crazy ideas. Not the ones like dancing naked on the bar in the latest club, but the one we think will allow us to rule the world. In those brief moments we envision pyramids, giant aligned rocks, and extremely good apple pie…with ice cream all served to us on a silver platter. When reality creeps back into consciousness we begin to think about the construction of that idea. This is where the prototype comes in.

Unfortunately, or fortunately, I have these kind of ideas every now and again. It leads to some entertaining day dreaming. When I snap to I begin thinking about how I could create that which I’ve daydramed about. It often leads to half attempted portions of an application. By the time I’ve finished hacking I have a subset of the functionality I imagined would work. This is the nature of the prototype; see a post I wrote earlier this year on prototyping.

Now, the constant Attention Deficit that I have due to my self-diagnosed N.A.D.D. means that as soon as my next big idea comes along I drop what I’m working on to persue that. This doesn’t work very well. It leads to a handful of half hearted attempts to produce anything worthwhile. Here are a few tricks that I use to make my day go more smoothly.

Break the monotony: In order to harness my ideas I tend to need to be fully engrossed in the concept. If I don’t have full confidence in what I’m doing then I lack the focus and attention required to be 110%. So, the way I combat this is by taking breaks. If I’m not fully into what I’m doing I give myself 5-15 minute breaks every 2 hours or so. This lets me recharge my focus by switching gears quickly over a short interval. Sometimes I’ll get up and walk around the office and chat quickly with someone about a random topic. But, it gets my mind moving in another direction such that when I return to my desk, I’m refocused.

Solve a problem: I try to solve problems. What I mean by this is not that I’m a problem evangelist, but instead that I work on the problems at hand rather than just trying to architect like crazy. I rather like not being an astronaut and prefer to stay that way. Plus, I tend to be far more interested in challenges, and problems present challenges.

Calling all units: When you code in pairs you have the interest levels of others to feed from. If you and another person or two other people are working together to solve a problem then you’re one step head of the game. I like to bounce ideas off others even if only for the brick-wall effect, it helps me to think through issues. When I grab another person to code with we usually end up being very productive pushing each other forward.

These couple of things help me to be as productive as possible. I try to use these techniques often as tools, just like my editor, in the sense that they can help me to be as effective as possible. When I’m done, I have a number of full featured prototypes that can be equally evaluated. This makes it easier for me or anyone to assess whether the idea really is something that can takeover the world…mwahaha.