I have been meaning to write an entry about programming and what we can learn about programming from Mihaly Csikszentmihalyi's book "Flow". Initially I was intending to write a rather scholarly article about it, but my work towards that end has lost momentum, so here--out of the desire to put forth something on this topic--is a less-ambitiously-groundbreaking-than-intended entry about learning to program better, and to enjoy it more fully, by applying the lessons of "Flow". Mihaly puts forth eight criteria that are typical indicators of being in the state of flow. They are:
The experience usually occurs when we confront tasks we have a chance of completing.
We must be able to concentrate on what we are doing.
& 4. The concentration is usually possible because the task undertaken has clear goals and provides immediate feedback.
One acts with a deep but effortless involvement that removes from awareness the worries and frustrations of everyday life.
Enjoyable experiences allow people to exercise a sense of control over their actions.
Concern for the self disappears; yet paradoxically the sense of self emerges stronger after the flow experience is over.
The sense of the duration of time is altered; hours pass by in minutes, and minutes can strech out to seem like hours.
I think anyone who enjoys programming can see themselves in some of those criteria. How often have you sat down and lost track of time, and come back to reality five hours later with this calm (although, sometimes raging) sense of accomplishment? This may happen to you frequently, or not, but lets think about what we can do to encourage it happening as much as possible.
We need to attempt projects that we can complete, but they need to also be projects that challenge us. Flow is the boundary between frustration (at difficulty), and boredom (at the lack thereof).
We need to find environments where we won't be distracted when we are doing real work. For simple programming sometimes its a relief to be interupted, but for creative work, to drink fully of the problem and grok it, we need to be isolated from outside distractions. This often manifests itself inversely for me, when I am stressed or frustrated I find it much harder to concentrate and produce clean code.This means that working in a crowded lab can often be detrimental. It turns the programming experience into a social experience--which tends to make it more fun--but seems to promote spagetti code (its hard to create code that smoothly flows and transitions cleanly, when we ourselves are programming it in disjoint chunks).
& 4. When I read this guideline, it screams in my mind " testing, testing, testing." This is one of the reasons I love unit tests (and also why XP likes them), it builds your mental state to go through the day getting positive reinforcement from your tests. If we don't test, we have growing doubts about our code's ability to run successfully (and rightfully so).The other side to this is organization, and having a clear list of functionality you want to implement. You ought to be able to track your progress through your unit tests, and also through functional tests (which parts of your intended functionality works). Its great to know you've written something that works.
The rest (5-8) are more descriptive than perscriptive, but they are still interesting to consider. In particular, I enjoy the seeming paradox of number seven. We learn to value ourselves based on what we are capable of, but at the actual time we are creating, we are unaware of ourselves (lost in the act of programming). Amazing to imagine oneself simply ceasing to exist sometimes, and THAT is when we do our best work--when we don't exist. A bit humbling in some ways (also strikes me as very much Zen Buddhist).I strongly recommend running out and reading Flow. Its great. Also, you might want to check out Blink by Malcolm Gladwell at at the same time. It hits some of the same stuff from a very different (but still interesting) angle. I'd love to hear any responses or comments!