Again, jaw hanging open, but this time in a good way.

I get rather alarmed at work when I’m told that someone’s idiocy is to be expected, as they’re: new, young, inexperienced, poorly trained, etc. I just expect better.

On the other hand, every so often I run across something truly brilliant, and feel humbled (Any book by Don Box). Today, I ran across “Duff’s Device.”

I’d heard of it before, but never bothered to actually look at the code. It’s an optimization for something I rarely have to deal with in real life.

Looking at the code today, I was at first confused by what the big deal was… then saw where the “do” was located, and was struck by the brilliance. Pick up the odd-numbers-out at the start, rather than at the end…

Only click the link if you don’t mind feeling impressed, and feel comfortable in your knowledge of what exactly a compiler does. Assembly language knowledge might help cushion the wtf factor.

Inconceivable!

I just went to clean off my white board (dry erase). It has notes from yesterday’s laborious explanation of the under-the-covers functioning of CoCreateInstance, so that my intern would hopefully be able to solve his own problem without my help (it didn’t).

I picked up the same eraser I used to wipe off the same board yesterday. I was erasing ONLY green, same as yesterday.

Somehow, my eraser left tons of black remnants all over my not-perfectly-clean-but-still-serviceable whiteboard. Black. I haven’t used black in weeks.

The only theory that comes to mind is that someone swiped my eraser and replaced it with this other one. Which is, in a word, inconceivable.

Different places, different work styles

Within an hour, I asked two coworkers to provide either myself or our shared lead with information related to the performance of someone I’m responsible for (my intern).

The guy who’s been with the company for a few years immediately told me not only what he had asked, but the context, and his impressions.

The guy who’s been with the company for a few months didn’t even say he was going to tell our manager; he just said, “Okay.”

It would make things easier for me if I know what he knows, but it’s more important that management knows how he’s doing. It just makes things more convoluted this way.

Review

I’m filling out my annual review form at work. We have to fill it out by EOD today, according to management, so they can have “calibration meetings.” They have to be sure not to give us a compliment unless everyone else agrees I deserve that compliment… (The real story is even more sordid. Stack ranking, bah.)

I also need to fill out Manager Feedback. I just got stuck on one question:

“My Manager ensures that others, including senior management, are aware of my contributions.”

I can choose Strong Agree, Agree, Neither Agree Nor Disagree, Disagree, Strongly Disagree, or Not Applicable.

There isn’t an option for, “I don’t know yet.” You see, I’ll be able to tell how well my managed informed senior management regarding my contributions, when I see a raise or promotion — in September. I don’t know how good she is at marketing me; can I trade her in for a new publicist? Maybe Paris Hilton’s?

What’s the point of asking me a question I don’t have a clue what the answer is, but have very strong feelings on?

Some help for the struggling programmer

#define sizeof(x) rand()
you can do that?
Yup
OMFG!
That’s disgusting!
qdb

After Jonathan’s post yesterday, I decided that I can pretend to be as wise as he is. So, now I present to you, my list of the first things that come to mind when I’m working:

  1. Corollary to Jonathan’s item vi: One of the highlights of Visual C# 2005 (aka C# 2.0) was the support for the “partial” class specifier. While C# improved on C++ (sort of) by ridding the world of header files, type libraries, etc., mandating the use of only a single file for a given class caused problems when things got too complicated. The “partial” keyword easily allows a C# class to be spread across multiple files, allowing code-generated portions to be in the same class, as well as easier editing. (I’m sure VB.Net has the same feature, but I don’t like VB.Net).
  2. A #region directive is most useful when you’re writing and editing code. When debugging, it’s mostly useless. When printing out code, it’s useless. But in order to keep subsections partitioned off either when you’re adding a whole lot of related code or when you’re implementing an interface and just want to “close it off” when you’re done, it’s useful. (C# again — would you believe I rarely write C# code?)
  3. Learning to use Windbg for your unmanaged debugging is priceless. You’ll lose some ease of use, but it’s:
    • Incredibly fast
    • apparently more accurate at both symbol location and source location than Visual Studio
    • the only thing to use in some cases, so it’s better to be familiar with it early on
    • got the best debugging feature I’ve seen in a long time: the “x Function” command, where Function can be a wild-carded search string… say you know you need a breakpoint on some function in some assembly shipped by your team. “x VSTO*!*ReportError” will return every function with a trailing ReportError implemented in every class in every DLL that is named starting with VSTO. It’s just useful.
  4. Never presume that other developers understand the difference between class and interface inheritance. Whenever someone starts casting from an interface to a class, begin getting suspicious. Whenever anyone explicitly casts from one interface to another not in a QueryInterface call, assume that that person may be making a mistake. Outside of non delegating IUnknown::QueryInterface implementations, there are very few places where that’s a good idea.
  5. The AddRef/Release Factory pattern is a very good one for a reason; ask anyone who’s ever had to track down a bug due to the difference in heap allocation and deallocation (Hi Jonathan!)
  6. Cross-thread logic is never as simple as you would like.
  7. It’s sometimes better to start debugging by observation, rather than jumping right into the debugger. Two minutes with SpyXX and a single breakpoint told me precisely where a bug lay in our code; a senior developer has spent several hours with no luck.
  8. On a related note: if a program isn’t responding to a button press: 1) it’s not handling the button press (correctly, in some cases), or 2) it’s not getting the button press. They’re both reasonably easy to verify with minimal debugging, and knowing which it is saves you hours of time.
  9. Debugging a crash that occurs in obvious code (ie, crash on a line: pInterface->Func() with a NULL pointer access violation) is far simpler than inordinately complex code — if it’s the former case the problem is usually right nearby or immediately obvious (the member was never set properly, a QueryInterface call isn’t being verified as having returned S_OK, etc.) The latter case usually will take a great deal of headscratching and puzzling and will eventually lead you to arcane bugs that occur somewhere entirely different — where the stack or thread data is getting royally trashed.
  10. Component != class; Interface defined in a header file != IDL / Typelibrary / IMarshal-capable component.

I’m done now. I’m not nearly as coherent as Jonathan, but I’m twice as angry. 🙂

Competency, just a bit of competency…

I came across a bit of code earlier today, and thought it was nice and creative; it uses the new lambda expression syntax to create methods that delay hooking up event handlers.

Then I discovered that this code was only necessary because the entire architecture was flawed. Now I have to go in and correct people who don’t know how to devise an actual architecture rather than a model of “new code.”