neurolinguistic gruntwork [03/22/2007 14:29:48]
I always feel a bit self conscious talking about NLP (neuro linguistic programming) because so much that falls under the banner of "NLP" is new age quackery and so many NLPers are freaks. But I still believe that the basic skills of objectively describing and redesigning subjective ideas can have a huge payoff. So here's an example.
I've been coming up with all kinds of ideas lately - for essays, projects, whatever. Being very creative. I realized a big part of my recent slump was that I was so focused on being productive that I wasn't allowing myself any time to have fun, whether that meant hanging out with friends or just playing around with ideas. I always worry that I'll get caught up in some spur of the moment idea and never get around to my plans.
Instead, I was trying to focus on making the cool ideas I'd already come up with a reality. The only problem is it all felt like grunt work. I mean I'd already done the interesting part of solving the problem in my head. That's how I got the plan. But once I had the plan, actually doing the work seemed so boring.
So for example, I could come up with a neat idea, and jump directly into coding (and maybe testing up front) and have a blast, but not necessarily come up with a great design. That's how I built turcanator, and that's why the code is a mess. On the other hand, I could jump into a design phase and work out the ideas up front, and come up with a much neater design, but then never get around to implementing it because it wasn't fun anymore.
In other words, I could write the code first, or I could write the design and documentation first, but once one was done, the other seemed boring. So I have a lot of fleshed out ideas on paper, and a lot of undocumented code, but very little in the way of complete systems.
My narrative programming concept was an early attempt to bridge the gap. (Incidentally, google now turns up some guy writing a book on narrative programming. It's dated 2001, but I swear I searched for the term when I coined it, and nothing came up. I wonder if his idea and mine are similar...) In any case, I still use "my" narrative programming to write tests, documentation, and code all at once, but it's hit or miss and not a discipline that really fits every situation.
So back to our story: I could look at either step and say: sometimes this series of actions is fun and sometimes it's boring, and the only thing that changes between the two versions is my subjective experience.
Aha. Time for some NLP.
The first step is to state the problem clearly. Here, I've got a lot of creative ideas, but I have trouble following through to a complete implementation. Once I've solved the problem in my head, I lose interest. So instead of going from creativity to productivity, I go from creativity to procrastination. The core problem seems to be that my normal problem solving routine tends to turn a bright idea into grunt work.
Well, from an NLP point of view, bright ideas and grunt work are just labels for specific subjective experiences. Whatever series of events would solve the problem, if my brain codes them one way, it's a fun idea, and if I code it the other way, it's grunt work. And generally, I start out with the idea and wind up with grunt work.
But knowing the label isn't helpful unless you understand the underlying structure. The structure of an experience has several parts. The major chunks are called modalities and they correspond to the five (or whatever) senses: sight, sound, smell, taste, and all the kinesthetic ones like temperature and pressure and body awareness and so on. Then these modalities can all be further specified with submodalities, which correspond to adjectives.
So, first step is to elicit one of the two encodings. I picked a neat idea. Specifically, it was the problem of converting midi data to a graphical musical score (sheet music) so I could add a module for reading music to turcanator. I hadn't solved the problem yet, so it was still interesting. The question is: how did I know it was interesting? What did interesting look like? Well, it turns out I was making two pictures in my mind, both about the size of a notecard. The top one was bright and clear: a screenshot of the musical score I was imagining making. The lower picture was a dark and fuzzy picture of the turcanator screen I already have.
So that's how I code "interesting" in my brain: a bright, clear picture of what I want, and a dark, fuzzy picture of what I have. (I also talked to myself about the picture - I have to talk it through in my mind for it to make sense.)
The next logical step is to contrast that with grunt work. I could have picked another project that I'd already solved and that now seemed like grunt work, but out of curiosity, I decided to just go through my normal process on the same problem. So I took a few minutes and wrote out how to solve the sheet music problem.
I don't want to go too deep into it, but roughly, I came up with these steps:
- take the midi data, which has note starts and stops and convert it to starts and durations
- create a thing that decides which staff (treble or bass) a particular note belongs on (this is an interesting problem itself, but a simple cut at middle C plus some manual tweaking would be fine for now)
- create a thing that maps pitch to staff position (for both treble and bass clefs)
- create a tempo object that maps duration to note symbol (whole note, quarter note, etc)
- a bunch of measure objects that contain chunks of music
- give each measure object a key signature object (to determine where to show accidentals)
- possibly also have a time signature for each measure
- measures draw themselves, and they need to know the previous measure so they can decide whether to draw the key and time signatures
- measures fill in things like rests and bars between eighth notes.
And so on. Pretty high level, but those are the basic ideas, and each one would be easy enough to implement, so I didn't chunk down any further. The whole process only took a few minutes.
As I was thinking through each step, I was making another bright little notecard in my mind, but once I recorded the answer in the text file I was working with, I discarded the mental notecard. It became very dark and gross, very much like the dark, soggy leaves I used to fish out of the pool back home. So the image of grunt work in my mind was the bright idea with a huge pile of nasty black trash in front of it. Grunt work.
Aside from not wanting to mess with those ideas, I couldn't even explain the plan to you. The plan was recorded externally, in my text file. If I wanted to think through the plan again later (or even go build it), I would need to go through the whole thinking process again, because the pile of soggy trash didn't mean anything to me. Or more likely, I'd just keep referring to the external plan.
So anyway, this mental structure is a good way to be unproductive and come up with piles of unfinished ideas. You don't need a degree in psychology to see the mental process is broken. There's simply nothing motivating about a pile of dark, wet trash.
So what to do about it? I needed a better internal representation for my plan. So I went through the planning process again, with my eyes closed, only this time, I kept the notecards and arranged them visually, as if sticking them on a bulletin board in front of me. It took a bit of practice, but after a few minutes I was able to keep the whole plan in my head, as a nice, bright timeline or storyboard. Now, rather than feeling like grunt work, the plan feels like a series of fun problems that still need to be solved with actual code.
The real test of course will be a work project - taking something that's already on my plate and rebuilding the representation in my mind this way to make it more compelling. I'm already off to a good start with my current project, though.
Anyway, this is the kind of NLP I like. Simple and practical. All it takes is taking the time to pay attention to your own brain, and suddenly problems and solutions become obvious.