preparing to get in the flow
February 21, 2009
Sam Wan writes about preconditions for a playful experience or how to prepare to “get in the flow.” He highlights 3 related preconditions:
- Memorizing a few basic rules and internalizing them into a mental model
- Practiced ability to iterate quickly without conscious thought:
feedback loop + muscle memory + internalized mental model - Immediate contextual information that fills in gaps in the mental model during active learning: code sense, tooltips, contextual documentation, quick jump to reference documentation
A few related posts where I’ve written about playfulness before:
- “It is the essence of play that a new relation is created… between situations in thought and real situations.” — Vygotsky Mind in Society (creativity as play)
- A few basic tactics to create a playful experience (work as play)
- “True education flowers at the point when delight falls in love with responsibility.” — Philip Pullman (less grammar, more play)
I’ve found it helpful to consciously separate learning from doing, but hadn’t thought about how it enables “flow”. I set myself to different activities and a different frame of mind when my goal is to learn (acquire knowledge, internalize a mental model and develop “muscle memory”), rather than when my goal is solve a specific problem (which relies on applying specific knowledge and “know how”). There was a specific experience that led me to be conscious of this separation of learning and doing.
When I was working on Shockwave at Macromedia and all this web stuff was new, I was assigned the task of trying out Shockwave as a windowless plugin. I was told that Jonathan Gay, the lead developer on Flash, made it so Flash worked in windowless mode in just a few hours. I set out the next day to figure it out. I spent the whole day reading and re-reading the meager documentation. I could find no code examples and didn’t want to dive into modifying the perhaps overly complex Shockwave code without having a clear understanding of a workable approach. By the end of the day I was frustrated an demoralized. How had Jon gotten this working in just a few hours? The next day, I decided to set aside my pride and just ask the guy.
So I walk over to his cube and ask him about it. He offers to send me over the working Flash code, so I have a good sample, which I gladly accept. Then I just have to ask: “I found the documentation to be pretty sparse and heard you got this working in less than a day. Did you find other resources? How did you approach it?” He replied that all he found was the same poor documentation, but that he had spent a few days experimenting and writing his own simple examples, then when he actually sat down to make the changes to the Flash code, it just took a few hours. I was floored. So this is how boy-genius does it.
By redefining the exercise into two tasks: learning about it and doing it, he accomplishes three things. 1) He frees his focus to learning all about the domain, what Sam might call developing his internal mental model and muscle memory; and then 2) applies that learning to the problem at hand, turning a complicated problem into a simple one, then 3) with a brilliant stroke of self-marketing, he excludes the learning time when reporting his accomplishment. In all fairness to Jon, I don’t think he was trying to position himself as the super star he is. He was accurately reporting how long it took him to modify the Flash code, reflecting how long it would take him to do a similar task in the future — pretty useful data.
What I learned from Jon was not the approach, since I would have followed the same practice of learning, then doing. What I learned was that by framing the experiences separately, I felt myself to be more productive, happier and found it easier to achieve “flow” during the learning phase, and that by tracking the time it took me to apply that learning, I had a useful data for estimating future tasks, and, of course, it always feels fabulous to get things done in a short amount of time.