Blocked on Chunking

I’ve been thinking recently about my difficulties with “chunking down” – moving my mind from the general to the specific. I actually don’t have trouble with getting other people to do this; I know all the right questions to ask, and I don’t hesitate to use them.

However, for my own personal projects or goals or just my thoughts in general, I tend to “chunk up” far more often: moving from the specific to the general, seeing patterns, extracting principles or rules of thumb, predicting trends, that sort of thing. My brain just seems to naturally go there, and stuff like that just “pops” out at me.

This has lots of advantages, certainly, but also a big disadvantage: I often have difficulty making progress on my personal goals and projects. As I’ve mentioned here previously, I usually have no problems doing other people’s projects, it’s only my own that I have trouble with. In fact, I often mouth off about stuff I want to do, so that then I’ll feel obligated to follow through, thus making my projects into “other people’s projects” by proxy!

Anyway, the practical difference (as Ty pointed out to me at the last Python meetup) is that for other people’s projects, the requirements are specific, concrete. The customer needs X, and they need it by such-and-such time. This allows for focus; we know what we are doing, we know what we are not doing, and we can then act without hesitation.

But this is where the chunking part comes in. To move from a general goal like “have a fulfilling life” down to specifics on a daily to-do list, is quite a bit of chunking down. I was watching a movie on TV today, and I saw a guy with nicely toned arms, and I thought to myself, hey, maybe I need to just work out one arm muscle, because that would be like the exercise equivalent of test-driven development. You test one thing, in isolation, and you figure out how to make that one thing work, and then – only then – do you move on to the next thing.

And although I’m not actually planning to do that – yet, anyway – it got me to thinking about how my inclination to chunk up to the big picture usually leads me away from accomplishing things. Because, usually, if I think about exercise at all, I start thinking about all the things I really ought to do, and before long I have this totally demotivating “big picture” of what all I’m going to have to do to get back into decent shape. In effect, I realized today that if I want to accomplish more, I need to start aiming lower, not higher, when it comes to my personal goals.

But I also realized, I haven’t really got a clue as to how to do that. So this evening, I turned to Google, and said, “O mighty Google of Googles, showeth unto me all that thou dost know about ‘chunking down’.” Well, actually, I just typed ‘chunking down’ into the Firefox search box, but you know what I mean. And I found some interesting things, including this “linguistic flashcard” for chunking exercises.

And after clicking on the little button a few times, I had a “flash” of insight: in order to do the chunking down, I had to decide what to chunk down to. When you chunk up, there’s a lot less choice involved; things are however they are, with a relatively small number of possible theories to explain the current facts. It is not, for the most part, a matter of choice in what things you perceive, when chunking up. Stuff goes into my brain, I perceive something, and there it is, nicely chunked “up” to a higher level of abstraction.

Chunking down, on the other hand, requires an exercise of choice; out of this big picture, what should I pick to focus on? Out of “great life”, do I focus on health? Career? Relationship? And all three of those things are still tremendously abstract. So pick one, narrow down again. And again. And again. At least four or five layers of decisions just to get to something focused enough to actually talk about doing.

With a client or employer, I don’t worry about this stuff because it’s their decisions that count. I let them set what’s to be optimized for, and then I make choices within those constraints to maximize the criteria they’ve chosen. Yeah, sure, there are actual decisions too, but there is still a frame of reference to refer to. For my own life, there isn’t really such a frame of reference, and my brain reels with recursion when I try to figure out how to set a frame of reference, without any frame of reference to use for what would be a good frame of reference to have. 🙂

Oh well, no new and dramatic epiphanies here. The fact that I look for and expect such epiphanies is itself a symptom of my bias towards chunking up. I tend to think my brain will have that flash as soon as it puts together the pieces of the puzzle. But now I think that I’ve gotten about as far in life as I can possibly go on that kind of insight; analytical insight has taken me to the point where I can see (with that same insight) that it’s not working for me, and that I need a completely different process to get much further.

A lot of times I hesitate before starting to code something, because I know that I don’t yet know how to code it in a way that will meet my criteria for a clean and usable framework, or how to describe it in the documentation in a way that will be readable, engaging, and informative. I hesitate to start because I know I will have to rewrite, delete, move things around. It’s messy, and I don’t like things messy. (Although you’d never know it from my office!)

But, the problem is that I don’t know, and I won’t know – can’t know – how to do those things until I do them. I keep putting off writing the full method combiner framework for generic functions because I don’t already know how it’s going to turn out. I’m hesitating to write the predicate functions and other syntax sugar for generic functions, because I don’t know where their documentation will fit in the big picture.

If I were writing the framework on contract or for an employer, none of these things would bother me, because there’d be a deadline and feature priorities and chances are good that half the stuff I’m fretting over right now, I just wouldn’t care about, because it wouldn’t matter to the job. I’d just get started.

So, tomorrow, I’m going to do just that. Get started. Tear off a chunk of the big picture, and work on it. I tell myself it doesn’t matter which chunk, and I’m probably right. I tell myself no matter how long I wait to start, it doesn’t significantly decrease the odds of making mistakes, even if it might decrease the odds of my thinking I’m going to make mistakes. However, even when I don’t think I’ll change my mind or make a mistake, the truth is that I often do. So, why bother going over stuff in my head over and over that I could just write out and see for certain what’s wrong with it, and fix it?

Heck, now that I think about it, that seems like a darn good idea. I’m really good at seeing what’s wrong with things, and pretty good at seeing how to fix them. If I just did things wrong to start with, in completely shoddy and haphazard fashion, I could then use my well-developed analytical skills to fix stuff up afterwards. Hm. Sort of like that old saw about good judgment coming from bad judgment, by way of experience. So, if I want to get good at doing my own projects, I need to first do them badly. 🙂

More specifically, I need to acknowledge the fact that I am not very good right now at making decisions that nail down specifically what I want, or prioritizing between things that I want, and tend to use other people to do some of the deciding or prioritizing for me. And, I need some practice to get better at it, but before I do well, I’m going to really suck. And that’s okay, because sucking at it is precisely what I need in order to be able to learn to do well.

It’s sort of like Kent Beck says in Test-Driven Development: By Example, “Clean code that works is out of reach of even the best programmers some of the time…. Divide and conquer, baby. First we’ll solve the ‘that works’ part of the problem. Then we’ll solve the ‘clean code’ part.”