More debugging

Seventeen days ago I had an insight. I wrote about it here. I decided to make an important and beneficial change in my life and break my conditioning.

And promptly forgot.

That was December 6.

That was 17 fucking days ago.

I forgot about it. Forgot that I had even written it, that's how deep my conditioning is.

Today I reinvented this wheel. For my future self's reference, the long form wheel-reinvention appears below.

The fact that I could have had what I thought was an important insight, decided to do something, and then completely forgotten about it is horrifying.

I've had moments of "awake" since then, but in not one of those moments did I remember my "awakened" intention work on debugging, and my intention to recondition myself.

Even more horrifying: I wrote a whole bunch of posts that day, almost nothing since, and didn't have enough sense to go back and see what I wrote.

I am going to try again.

It's clear my conditioning is much stronger than I realized. I need aids and help if I am going to break it.

So on a piece of paper I have written "Debug" to remind me.

I have written this post as penance.

I will enlist some friends in the effort.

And I will post some of my notable debugging insights.

For the record, I tried four times(!) to write a new post about debugging before I realized that I had written one before.

Here's the CFAR post that kicked this off the first time.

Below, my earlier attempts, all written without recollection of having been here 

(Don't bother reading. Historical interest, only)
Debugging

I'm trying to develop a debugging mindset: when I see a bug, then if I'm not under time pressure, I fix it. Right then. Like right now: I'm writing this post, which is an interruption of another post because I ran into a bug and I wanted to document what I did.

And there's another bug, right there. What I wanted to do is simple: I want to document my debugging mindset and give an example. Instead I've sidetracked into explaining what I was doing, how it came about, etc. So let me start again.

I've decided to develop a debugging mindset about what I write and what I do. If I see a bug, and I'm not under time pressure, I want to stop, analyze what's going on, fix the problem, and move on.

A common bug is distraction. I'm doing something, and I veer off to something else and often don't come back to the original task until much later.

But underlying the distraction is lack of clear intention. I started this particular post with a vague intention: "Write something about debugging mindset." And, as you can see from the first draft (below) I started wandering pretty quickly.

To focus my intention I want to try doing this--for this post: start with a summary; define my terms. Give an example of the problem. State the solution.

So try three:

When I find myself doing something other than what I've set out to do, it's due to a bug in my cognitive processes. After all, it's my cognitive processes that are driving my behavior.

Usually, I ignore the bug. A better idea is to stop, fix the bug and move on.

Example: distraction. I'm writing something, and I get distracted. As soon as I realize I'm distracted, I need to flag it as a bug, figure out why I was distracted, and how to correct whatever is under that.

Example: I'm writing something and I want to check a reference. Usually I will unthinkingly do the research. Better is to slug a TK into the essay and do it later. If the reference is critical to what I am writing I may not be able do do that. I might have to take the process back a step.

Try 4:

I know my cognitive processes are buggy. Everyone's are. The thing is: am I looking to spot bugs? And when I spot one, what do I do?

Until now, my MO has been: occasionally spot bugs, but mostly, just keep going.

And when I spot a bug, I might ignore it and follow my flawed thinking, or I might hack my way around the bug and return to what I was doing.

Now I am going to actively look for bugs.

And when I find one I am going to analyze it, find the root (or as deep a root as I can find) and then fix that root.

Evidence of a bug, by my definition is: any time results don't match intention, that's evidence of a bug.

So I need to have a clear intention--otherwise what can I compare my results to?

I need to continually monitor my result versus that intention.

I've done that several times in earlier drafts of this post. The earlier versions are below.

The underlying poblem for several of these bugs is that I start writing without a clear enough idea of what I want to say, and perhaps who I am saying it to.

So for this one, I knew I wanted to say: "I am going to look for bugs and fix them when I find them, if I have time" To say that, I need to first define what I mean by bug.

So my plan is going to be (for the moment) to write things to different bugs