coding in flow, part II [0208.2000]

I talked a month ago about building a "flow" state for computer programming on demand, but using freewriting to get the brain "in gear". I can personally say that this technique has worked wonderfully every time I've sat down to work. But, as Elan correctly observed in an email to me, there's something missing: the freewriting technique helps with doing things right, but it doesn't help us do the right things. We've moved from a lightbulb to a powerful laser, but now we need to aim it, and that's what I'd like to explore here.

One of the benefits of a flow state is an intense focus on whatever happens to be in front of us. This is wonderful, because we stay on task, work quickly, and generally accomplish our goals. But it also means that we're so focused that we don't have time to consider whether or not the problem we're solving actually needs to be solved right now.

For example, before I wrote Coding in Flow I, I'd only get into that state by accident, by following some line of thinking to the point that I became fascinated. Once I got there, I'd code (or talk, or do whatever) for hours on end, and nothing else mattered. Unfortunately, most of the things I focused on this way had nothing to do with my long term goals. So while I'd spend countless hours studying lojban, spanish, java, XML, or MIDI (just to name a few), my actual "work" often failed to interest me. Worse, I'd sometimes even forget about my true goals for weeks on end.

When I ran out of money and had to go back to work, I knew I needed to tap my ability to code in a flow state, or I'd get frustrated. So I modelled my process for naturally getting there, and synthesized it into the freewriting exercise. Now I'm able to fully "step into" any programming task that I need to accomplish, just by making the conscious decision to sit down and do it, and by spending a minute or three freewriting.

Now I know how to turn on the laser. But how do I turn it off, or keep it from being turned on accidentally? How do I make sure that I don't point it in the wrong direction, and turn some "toy" goal - for example, getting python to record note from my MIDI keyboard - into something that gets in the way of my real work? Further, how do I *keep* the benefits of my wandering focus: things like creativity, exposure to new ideas, skill development, useful byproducts, having fun, etc?

My intuition suggests several approaches to consider:

• put off "toy" projects until I get the "real" work done
• set limits on the amount of time in a programming session
• set limits on the scope of a programming session
• create a tool to "remind" me to stay on track
• schedule coding sessions throughout the day
• use a tool to compare estimated effort to actual effort
• make toy sessions flexible, "real work" sessions less so

That's about all I can think of at the moment.. Let's look at these a bit closer:

put off "toy" projects until I get the "real" work done
I've tried this. It doesn't work. Remember the Hydra from Greek mythology? You cut one head off, and it grows two in its place. Well, if I toss one toy idea, I'll have two more coming around to replace it within the hour. I still get caught up in them.. It's just a series of short drifts instead of one long one.

set limits on the amount of time in a programming session
This seems sensible both for keeping hobbies in check and as a means to pause and regroup for real work. I'm thinking hour or two hour longs sessions would fit right for me.

set limits on the scope of a programming session
This is actually useful for several reasons. First, if I use it in conjunction with time constraints, I can start to track how well I accomplish goals compared to my estimates of what I think I can do. Second, it would force me to plan across multiple sessions, which means I'd have to break the problem down into pieces. This would give me a better handle on work, and force me to evaluate whether I really want to go all the way with toy projects.

create a tool to "remind" me to stay on track
This was actually going to be my first Java program a while back, but I never built it. (I also looked for something like it on the Palm, but have yet to find what I want).. It would be like an egg timer, with a few modifications: a) it would ping me when I need to start "cooling down".. b) it would chime at random intervals to remind me to stay on track... c) it could be paused (for phone calls, etc)

schedule coding sessions throughout the day
The important word here is "schedule".. Eg, work around things like meals, workouts, appointments, life, etc.

use a tool to compare estimated effort to actual effort
I never realized this, but this is probably one of the most useful features of a tool like microsoft project. Once I've broken the goal into subgoals and then into coding sessions, I can use a simple tool to track my progress in completing the entire project.

make toy sessions flexible, "real work" sessions less so
I may be all about MIDI today, but tomorrow I'll be all about the new time management software I'm cooking up in this essay. If I just schedule "toy time", I don't really have to decide what I'm going to work on, as long as I use it for *coding*, or researching in order *to* code..

Why? Because.. Because the goal of toy time is to make me a better programmer in my other sessions. If I use it to study spanish, not only do I miss the point, but I won't get my "fix".

I guess that's it. I've wanted this kind of thing for a long time. In fact, it ties in with what I want to build for manifestation.com, which is one of the "major goals" I've been putting off.

So.. It looks like tonight I'm going to try my first new-style coding session.. probably a design session.. working on the msdc backend. Cool! (Tune in next time for the results..)