Analysis Paralysis

I've seen this happen to people before. They are given a problem with some really thorny cases and they thrash. Me, I think with my fingers.

Thinking with your fingers can be dangerous. For example, the first code you write, the first code that solves the problem, is never the right code. Thinking with your fingers involves refactoring. Sometimes you need to throw everything out and start again but this time, you know the problem space.

You can thrash with your fingers too. You'll know when you are thrashing. You hack and get nowhere. Everyone has experienced that sinking feeling. When that happens, turn the computer off! Go talk to someone, google or read a book. You are not alone.

There is another version of analysis paralysis that affects managers. It leads to defeating meetings, phone drone and endless email. I won't discuss that in case I get fired. Besides, I don't want to limit my advancement opportunities.

Steve

I hate Windows

Ok, now I have your attention: I don't really hate Windows (any more than the rest of them). So what did Windows do to me this time you ask? We were looking good for Eclipse 3.3 RC2 when this came in.

On Vista only (win32, not WPF) , it turns out that TVM_GETNEXTITEM is really slow when called with TVGN_LASTVISIBLE during a tree item collapse when the item that is collapsing has more than 23 children and each child has at least one child and the collapsing item that started the whole thing going is about to become the new absolute last item in the tree. All this has to happen during a WM_NOTIFY for custom draw (NM_CUSTOMDRAW with subcode CDDS_POSTPAINT) or it's not slow. You got all that?

Obviously, we have a broken fuxit .... as in, "What the fuxit doing?". My guess is that some cache way down deep in Windows is getting invalidated and someone is linear searching every item in the tree multiple times.

Fortunately, SWT has no custom C code (yay!) so it was pretty easy to find the system call that was taking the time and come up with a work around. Even though the work around code will run on XP, I'll probably guard it with a test for Vista. After all, we're closing in on RC2. Gotta be careful.

Steve

Is that new IDE feature worthwhile?

I'm a simple guy and live by simple rules. One of them is: "That which obscures my code is bad". This rule isn't hard and fast, but generally turns out to be true.

For example, the red squiggles that show up under your code (sometimes called "the red sea") are good. They tell me I have compile errors and let me see my code at the same time. Automatic Javadoc or code assist (sometimes called "code desist") is bad. It can steal focus, misdirect keystrokes, obscure code, insert random text fragments, slow my typing and most of all, confuse and frighten me. It's a completely different story when I ask for it. Then I'm not afraid.

It's hilarious watching people give demos, fighting with their IDE as it inserts unwanted code fragments which they immediately delete. Fortunately, Eclipse allows you to configure everything so you get to choose whether you are being helped or hindered.

Steve