dirtSimple.orgwhat stands in the way, becomes the way

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.”

Join the discussion
  • You might like “The NOW Habit”. It has a section on how negative framing of things into “I must do…” or “I should do…” is counterproductive and should be replaced with “I choose to…” or “I deserve to…”. It is more positive results oriented thinking, etc. Good book for other reasons as well.

  • It sounds like you need to get yourself on an XP team for an iteration 🙂

    Right now, I am building my own product, which makes me my own customer. Having just done XP for the last 9 months, I’ve got the rhythm pretty well ingrained. I write “user stories” for myself (again, I’m the customer), I estimate them (based on imperfect knowledge) and every week I schedule what I think are the most important of them. The cycle forces me, week by week, to evaluate the priorities and the costs.

    You’re already on to the whole test driven development thing… It can be really hard to do the simplest thing that can possibly work when you’ve been doing things “the old way” for years, like I had been. I still don’t take things to Kent’s extreme (like making a method return 5, because that’s what the first test was looking for). But, it is liberating to focus on one bit at a time.

    And, I think it does actually do good things for design. I’ve never taken XP and TDD as licenses to turn off your brain. So, I created a Swing GUI framework in fall 2003 knowing that I needed something higher-level to support the number of screens we would need. I built the framework entirely test driven with only a high-level sketch of where I thought it should go. That worked great, and I think the final design was nice.

    If you ever find yourself in Ann Arbor, Michigan, I can hook you up with some folks that can drop you straight into an XP environment to try it out 🙂


  • “””It sounds like you need to get yourself on an XP team for an iteration”””

    XP as in eXtreme Physical fitness? XP as in eXtremely Practical housecleaning? If not, I don’t think it’s gonna help with my personal non-programming projects. 🙂

    And, in truth, it wouldn’t help with the programming projects either, except for the fact that the social situation would cause my “other people’s project” mode to kick in. However, part of the point of this post is that I’d like to get past using the trick of turning my personal projects into other people’s projects in order to make progress on them.

    I realize that you’re suggesting that I transfer XP techniques, but the nature of the “bug” in my programming until today was that I try to apply *all* possible requirements/criteria simultaneously without eliminating any, in the absence of criteria provided by those “other people”. So, it really didn’t *matter* what techniques I did or didn’t use; the bug was cleanly portable to any level of recursion of attempted workarounds. 🙂

    To put it another way, it doesn’t matter what input you feed to a broken operating system, and my personal OS had a rather nasty bug up until today. (See today’s post on The Primary Inhibition for the story of that bug and its resolution.)

    So, although there’s a lot about TDD in this post, the emphasis is really on applying TDD to the *rest* of my life besides programming, and only using a programming task as an example because I don’t really feel like spilling all the details of my personal life here. 🙂



Stay In Touch

Follow our feeds or subscribe to get new articles by email on these topics:

  • RSS
  • RSS
  • RSS


Get Unstuck, FAST

Cover photo of "A Minute To Unlimit You" by PJ Eby
Skip to toolbar