Yesterday, per my plan, I got in there and tore off some big chunks of the method combination work for generic functions. Just now, I was about to start in on the next phase, which was going to involve some additions to the current doctest to begin explaining and using some not-yet-written functionality. And I noticed that I was hesitating to start, because I was trying to figure out where in the documentation this particular functionality should be explained and demonstrated.
I had already noticed yesterday that it really didn’t matter where I put something; any spot would do, because it was going to get moved and edited as things went on, no matter how good or bad of a place I chose initially. But today, my mind was rejecting every place I initially considered as a candidate for placing the new functionality, as not being the “right” place to put it. As soon as I realized this, it was like finding the cause of a difficult-to-locate, longstanding bug in a program. Duh! So that’s where the problem is!
I was previously aware in a general way that my impossibly-high standards for myself can get in the way of accomplishing things, and the other evening I blogged about precisely that. What I was missing was that this is actually something I can get my hands around, as it were. It’s not just some sort of abstract concept, it’s a concrete, specific behavior that occurs in a particular context: when considering options for doing something, I’m validating them against criteria.
Well, that’s not actually the problem. The problem is what criteria I’m using. For “other people’s” projects, the criteria are whatever they’ve said is important, and any consequent criteria that arise therefrom. For my own projects, the criteria are whatever I happen to think of at that moment, or have previously thought of – which means that there is an ever-growing set of criteria to which my personal efforts are subjected.
Thus, over time, as I learn more and more about how to do things well, the less effective I actually get in my personal life! (On other people’s projects, I tend to filter these additional criteria according to their impact on the client’s criteria, so it doesn’t interfere nearly as much.)
I feel so stupid, because Ty and I have actually talked about this issue before, and it was right in front of me all along. We knew that defining criteria for personal projects was an issue, we knew that excess personal criteria were a problem, and that we needed to change that.
What we didn’t see – or at least I didn’t – was how to do that. The mind isn’t like a program whose source code you can inspect; to work on a piece of “brain code” you sometimes have to be able to “break into the debugger” when the target code is actually running. I did that today, so I now know precisely where the bug occurs.
Better yet, I think I know how to fix it. The primary inhibition code I found in my head is, “don’t do the wrong thing”. This is a simplified form of the actual code, of course; it contains a mixture of ideas such as not making mistakes, not redoing work, doing what is justifiably correct with reference to external criteria, and so on.
But the primary intent is to “avoid wrong action”, where “wrong” is defined as “not right”, and “right” is a function call to everything I know about what “right” might be, be it with respect to “right for business”, “right morally”, “right technically”, etc. (Luckily, the mind runs on massively parallel hardware, or this code would be slow, in addition to its other issues!)
Anyway, the fix is ridiculously simple: just bump down the priority on those criteria, putting a filter in place to only inform me of issues with potentially serious or costly consequences that cannot be undone. Cutting and pasting documentation and doing some rephrasing of it doesn’t count as serious consequences. Another way of thinking about it is this: don’t tell me what’s wrong, tell me if there’s something to do that’s right. (With the exception of serious irreversible consequences, of course.)
Of course, I’m going to also have to “write some new brain code” for that latter functionality. It’s sort of weird to realize that I have this enormous database of “shoulds” and “shouldn’ts”, but that neither one is directly very useful for deciding what to actually do; they’re just criteria for evaluating possible solutions, not generating them. However, at least in most low-cost/low-pressure circumstances, it will suffice to just do anything, then use my shoulds and shouldn’ts to improve whatever I did until it’s good enough to leave alone.
So now, as with any bug fix, I also want to do a post-mortem. How did this bug arise? How can I avoid creating such a bug in the future? Were there warning signs I missed? Did I have any knowledge that I did not apply here?
In retrospect, I’ve read plenty of things that advise “painting badly” or “writing badly” in order to get past one’s inner Editor or Critic. However, I always viewed this as some sort of ploy for getting started or getting past a block, and even when I’ve resorted to it in the past, I’ve always immediately discarded it thereafter. After all, it wasn’t the “right” way to do it, it was “cheating”. Thus, it never occurred to me to change the thought process that would lead to such a conclusion in the first place!
There’s an Emo Phillips joke that goes something like, “I used to think that the brain was the most interesting part of the body. Then I thought, ‘Wait, what part is telling me that?’”. This is the most annoying thing about brains: your thinking is filtered through your current perspective, so you can’t directly detect any systematic bias or bugs; it just seems like it’s the rest of the world that’s messed up! It’s almost like having compiler bugs: the code actually being run is not the code you think you wrote. Only the program’s output will tell the tale, but only if you look closely enough – and not necessarily in a way that points to the compiler bug! – leaving you with no alternative but to single-step your way through to finding it.
You could put some artifical limits:
Don’t refactor until it’s done. Don’t add anything while refactoring.
Write down tasks. Don’t do anything else but top priority. (You can put task “refactor for 40 minutes.” in the pile as well)
When you are stuck for some fixed time (say 1 hour) do 5 minute resorting of priorities. 🙂
Ģirts Kalniņš
I also wonder if changing speeds could help. Like one easy task, one hard, one easy, one hard. So you don’t have emotional routine.
Giving advice is a lot easier to do than following it. So, here’s as much for you as for me 🙂
# TODO: get in brainstorming mode
# TODO: write item to do
# TODO: research on procrastination
# TODO: write a macro that outputs “# TODO:” by typing CTRL-T
# TODO: Make sure to spell check this post
# TODO: Move this item up, as the spell-check must come at the end.
After a while, your to-do list might be broken down in so many small topics, and starting to become coherent after moving items around that you might reach a point where you will start to transform “# TODO:”s into actual lines or code …
or not.
“””# TODO: write a macro that outputs “# TODO:” by typing CTRL-T”””
LOL. That’s hilarious. I know you meant it as an example of loosening up to get started, but it reads more like my *actual* to-do lists tend to end up, with tons of elaborate prerequisites that don’t contribute as much as just getting started would. Thanks for the laugh. 🙂
“””You could put some artifical limits:…”””
I’ve done and do those things lots of times; they don’t really relate to the “bug” I was talking about here, which is about correctness criteria preventing me from doing anything but *thinking* about starting. The rules you mention only help once I’ve actually started. 🙂
Although, it does suggest a different way I could’ve fixed the “bug”, by defining it as “wrong” to not start things. But now that I think of it, I already did define it as such, it just that *not* doing things wasn’t as “wrong” as actually *doing* something wrong, so it didn’t help.
But I digress, and I should probably go now and actually get something done, as between posting this, replying to comments, writing about PEP 246 on Python-Dev, and wiping out comment spam, I still haven’t actually started on the method combination code yet! 🙂 (For that matter, I haven’t gotten up from the computer to have breakfast yet, and it’s now 5pm already. Apparently, writing takes me a *lot* more time than it feels like it does.)
Heh, then probably You need to scedule fixed time for food, sleep and excersise 🙂 Too much thinking.
Man, you are clearly suffering from being “abstraction prone” which is “similar to being accident prone, except instead of falling down, you tend to be drawn upwards.” Your frontal cortex, the center of planning, is on fire with neural energy, tying itself in knots. Careful, not long ago the therapy would have been lobotomy. 😉
But your being abstraction prone is very good for Python, and you don’t seem to be blocked by any normal human standard. So take time to relax, let that anxiety go, and keep up the great work!
I feel your pain. It seems like most decisions in life are like a chessboard. You do not know what your next move should be, because of the combinatorial explosion; and it is not like you could go back in time either.
Afortunately when you are programming you can always decide to refactor and do it differently. And any good programmer understands that perfection comes from iteration.
Nestor
Great post..
I too suffer from compound meta-abstractionitis in certain design+dev seasons. But last year in New York it got pretty serious in a bad way for me. I found some insightful reading about procrastination behavior archetypes. Here is a good fast intro:
http://mentalhelp.net/psyhelp/chap4/chap4r.htm
Then somehow I was inspired me to sign up with a terrific Alexander teacher downtown. Alexander’s idea/philosphy of ‘use of the self’ is brilliant but not easily articluated. A classic case of experience vs. description it’s now-zen+meta
Weekly lessons and very simple daily practive for a few minutes at vqarious stages of the day, quickly gave me an fascinating and very welcome personal paradigm shift. The last thing I expected, and it’s not a phrase I use lightly. Helped on so many levels, including the obvious, but essential issue of eating rhythms, just be-ing and non-intellectualized awareness. Re-energized how I look at all the wonderful intoxicating program and meta-design constructs and dreamings.
What a difference a day makes..
Other reading included Steven Covey and his famous quadrant algorithm which maps ‘important’ ‘not important’ against ‘urgent’ ‘not urgent’.
In itself a sriprisingly elegant approach which can be recast how you will
Recently I’ve started on implementing a big project which feeds of all the previous. Wondered how to grapple with some the problems you describe. So I started using ‘Leo’ as an suitable tool for pragmatic meta-programming and design thinking.
Maybe you’ll like it.. of have not tried it already
To a considerable degree, Leo does lighten the issue of where and when you put or name things things, becuase it’s design recognizes that structure and context deserve equal billing with content and function.
It does that by a few simple very powerful ideas.
Great when you have to mix outlines with source code from several pangauges, file formats, data sources, comments, structural planning etc. Althoug it si wrtten in Python, it’s open to all
http://webpages.charter.net/edreamleo/front.html
Hope this helps. I really enjoyed you writing and thinking. Good luck and thanks!
Jason
“…all those who wish to change something in themselves must learn to make it a principle of life to inhibit their imediate reaction to any stimulus to gain a desired end, and…they must continue this inhibition whilst they employ the new direction of their use.”
— F. M. Alexander
Did you see the “The Bicentennial Man” movie? Your conclusion strongly resonates with the one the main character reaches near the end of it (and near the end of its process of humanization). “In order to do the right thing, one must sometimes do the wrong thing” or other words to that effect.
I don’t recall it being present in Asimov writings, neither in the short story, nor in the novel: it must have been made up by Nicholas Kazan, the screenplay writer (as many other things in the movie).
Check out this web site if you suffer from chronic procrastination, there is a healthy discussion of what works, plus we provide each other with support.