“Flow”

Getting in the flow is a concept that is familiar to both programmers and musicians. Flow is a state of immersion, where productivity peaks, and stream of genius and creativity literally “flows” into the fingers.

In Designing Musical Instruments for Flow, Spencer Critchley writes the path to “flow”:

1. Immediate, meaningful, physical feedback
2. Natural, ergonomic control
3. Aesthetic pleasure
4. Capture a wide range of input data
5. Technology should serve simplicity
6. Progressive complexity
7. Activity oriented design

Empirically, the points above explain why languages like Python, Ruby appeal to programmers. Not having to statically type generates a great deal of “flow” - technology serving simplicity¹. Library documentation which includes useful working examples aid this as well, as is a library API that is accessible - activity oriented design^{2, 3}. Duck typing captures a wide variety of input data. REPL mode - immediate feedback. ⁴

One might think progressive complexity having has less to do with flow, and more to do with accessibility and usability. This is not true. Progressive complexity means that “newbies” get into flow quickly too, and provides the positive feedback which encourages them to persevere and refine their skills.

What about non-programming software? Working with spreadsheets puts me in the “flow”, but working with Word doesn’t. Perhaps this is because working with spreadsheets is repetitive in nature: set up a formulae, and then the rest of the operations are copy and paste. Perhaps it’s because the key bindings for spreadsheets make light work of repetitive tasks. Perhaps it’s all of the above.

Perhaps, with Word, writing is such a creative process, that I find - especially as a non-native speaker - that it is easier to get distracted by the variety of ways in which I can reformat a paragraph. In fact, I find it more productive to work in WordPress than in Word because of this.

Last - but definitely not the least - let’s not forget the contribution of search engines as the ultimate flow-generator. Most typical programming problems have been solved before by someone else. Having ready access to this knowledge makes it easy for developers to work-around those 10% problems that normally take 90% of the time.

footnotes

¹Patrick Logan is right (dead link) about static (dead link) type (dead link) checking not being very useful, but he didn’t emphasize the point that people tend to statically type even when it is optional. In fact, it is a matter of discipline not to statically type when I program in VB. I have to consciously leave variables as variants while code is being prototyped.

²Look at the .Net api for saving an Image, how many people will be able to save an image to a file without looking at the sample code? Compare the DotNet sample code with the one in python. When I want to eat cake, please do not offer me flour, eggs, and sugar.

³Joel Spolsky offers a simpler view on where flow comes from: just being able to get started.

⁴What does this say about a web-based environment for developing programs? Environments such as Zope, and JotSpot? Applying the rules of flow tell us that, everything else being equal people will prefer a medium that offers faster feedback. I know that large chunks of my Zope development is prototyped through the web, and that was good enough. We wait eagerly to see the outcome of the JotSpot experiment for another data-point.

Bibliography

Mihaly Csikszentmihalyi, The Evolving Self.

Mihaly Csikszentmihalyi, What Is Enlightenment magazine interview