Pragmatic Geek

I reached a milestone today with my GTD project: it became usable enough that I can use it to track what I’m working on for its development.  In programmer’s parlance, that’s eating my own dogfood.  Granted, the food tastes pretty bland and requires extra chewing, but it’s edible.

A lot of personal projects are born out of the desire to “scratch an itch,” and this is no exception.  I’ll probably write more in the future about other itches, but for now, I’ll talk a bit about how this scratches my multitasking itch.

I am a vicious multitasker.  Some folks call it a blessing, others a curse.  I believe it’s driven by my desire to constantly be doing something that I will rarely allow myself to sit and be idle if my current task is waiting on something.  Things like long compiles, people typing slowly into an instant messaging window, or waiting for the microwave to heat my coffee will all cause me to take a tangent to something “more productive.”

That said, I acknowledge:

1. There’s no such thing as multitasking.  Just really fast switching of attention.
2. Going off on a tangent to fill an idle time slice often gives that tangent more time than it deserves.  Things like scanning the news headlines turns into reading at least 1 long article.
3. Returning to a task takes a non-zero amount of time to re-acclimate to the details.  The longer you’re away from the task, the longer it takes to re-acclimate.

My “itches” around this issue fall into a few areas

1. Explicit task focus.  The system should try to keep attention on the current task, and not allow the focus to be lost with a simple alt-tab to another app
2. Minimize distractions.  When working on a task, keep unrelated things out of sight.  This is related to what I was talking about the other day, about data vs. task.  Most systems try to put as much data on the screen at a time to make it easier to move between items.  But that’s because they don’t know what your current task actually is.
3. Accommodate interruptions.  When interruptions occur, explicitly acknowledge them, and try to help save the state of the task that is getting interrupted.  

The first thing this system does is exert the task focus.  I requires you to pick a piece of work, and you can get out of that work with either a “done”, “put away,” or an “interruption.”  Every screen reminds you of what you said you’d do.

It’s been a fun week of vacation.  As I told my co-workers, it’s not like I wasn’t going to be in front of a computer on my vacation, it’s just I’d be in front of a different computer.  I’ve also been using this as a chance to explore Grails, and I’m pretty impressed.

I started my first Grails project today, using the basic project in NetBeans.  I was going to start with vanilla Groovy, but learning thick client Java seemed like more work than going whole hog into Grails.

I’ve said for some time, I’m scared to try Groovy/Grails, since I’ll probably get angry at all the time spent doing plumbing work rather than real code.  I’m on track for that to be true.  Some of the things it does by default are just scary – the scaffold pages for list/view/edit are pretty.  

The prototype I’m working on goes beyond a basic CRUD app, but I could see how this framework closes a RAD gap for the java world.

Google has been my friend – almost any question I come up with has been answered in a blog post or email message.  I haven’t acquired a book yet, although I probably should.  A series of articles at IBM developerWorks has also been a good start

Some vagaries I’m stumbling on

• When does hot deploy work or not?  Some changes are immediately viewable (and my Bootstrap method has been refreshed), and others require restarting the app.
• Why doesn’t code completion work in BootStrap.groovy  (Netbeans 6.5)