After yesterday’s insight (see the end of the post) about “confusion headaches” that come along with my self-brutalizing style of learning, I’m curious how today’s creative activities will go. My theory is that I’m frustrated by the “deferred answer” situation that arises when I try to fulfill my systems-based approach to learning from mediocre documentation, and this is what generates the huge nap-inducing headaches.

This might be the demarcation point between “creative” and “creative support”. I’m reminded of a paper by (I think) Vannevar Bush where he (or maybe Douglas Englebart) says that the moment of creative work happens only after mundane clerical work** has been done to support it. And that’s what happens to me when I’m studying, say, a new software development tool that is unfamiliar to me: I need to absorb and organize a lot of concepts in my brain or on paper so I can see it all at once, and then the connections happen.

In terms of creative support for this specific problem, I think I can just accept that documentation sucks, and pull what data I can get from it. It may not be complete or even well-defined, but it’s a starting framework. I’m creating a set of lists, basically. Before, I was frustrated because I wanted to get on with the work, and I found the documentation an obstacle rather than a source. The negative feelings and mental burden conspired (I theorize) to create a huge headache. I remember the feeling well when studying various math courses, which have the worst documentation ever. I do find it interesting, though, that other people don’t seem to have a problem learning from the material, and they don’t seem to have headaches about it. What are they doing differently? Yesterday, it took a mere HOUR of pushing before I had to take a long nap. Perhaps they don’t have the same resistance, or have a different learning strategy.

Anyway, today’s thought about dealing with the frustration is to ease-off the desire for immediate gratification of my learning goal (“be the master of time and space and NodeJS”) and settle for acquiring useful data in a relaxed timeframe. My investigative design approach has a rule of thumb that I need to remember: “no one is telling the whole truth, but no one believes they are lying either.” That rule of thumb puts me in the mindset to discover the real story, and that requires a lot of mundane forensic data collection. In this case, the data collection comes from existing documentation, and that makes the goals more immediately achievable. The reward, then, is no longer quite as deferred. At the same time, I can also remember to turn off my brain, and just do data processing and term recognition WITHOUT triggering the “well, what the hell does THAT do?” subroutine that can never execute to completion.