Communication patterns and diversity

Someone recently sent me a tool which measures whether your brain is left/right-hemisphere dominant, and auditory/visual. I am left+visual, and prefer logic and visual patterns. In a discussion I will find myself going to the whiteboard, even sometimes when it's not necessary, and highly prefer people draw their ideas out because I like having something to stare at.

Anyways, this sort of thing gets interesting when you have two people at the opposite ends of the spectrum. When they are trying to communicate, the visual guy may be drawing a diagram and asking "Why can't you see this?" to the auditory guy, who is thinking, "Why can't you hear what I'm saying?". Other communication examples are where one person wants to discuss big picture and the other wants to start with the details, or where one person prefers face-to-face and the other prefers e-mail discussions.

With a diverse group of people, the challenge is understanding everyone's points of view and having both sides alter their behaviors to accommodate each other. I've heard someone tell me that each slide in a presentation should have at most one sentence or picture, and bullet-points are the work of the devil. But I think a good presentation should appeal to both auditory and visual people, and not just one half or the other. As another example, a meeting with documents sent beforehand, provides face-to-face time via the meeting while allowing people to send questions/comments via e-mail. Small behavior changes like these make all sides feel comfortable and help everyone communicate successfully.

If you think Microsoft code is bad, you should read DailyWTF.  It has great coding patterns like:

   try
   {
     int idx = 0;
     while (true)
     {
       displayProductInfo(prodnums[idx]);
       idx++;
     }
   }
   catch (IndexOutOfBoundException ex)
   {
   }

And sweet UI dialogs like:

   Cancel print job?
     OK | Cancel

And stories about "C-Pound".  Yes, geek humor.

Writing Office client code

Writing Office client code is ... an experience.

First, everything is in unmanaged code, which means each line of code takes 5 minutes to write.  Why?  Because you have to check the APIs every time, to make sure you know who owns the memory and what the exact parameters are.  If you don't, you will get an intermittent AV or corrupt the heap and crash the app.  And, since none of the APIs are documented, you have to go trolling through the sources to figure out what the hell's going on.

Second, you get to use classes with interesting names.  For example, their web service APIs are still called things like HSUser -- long live HailStorm!  Then you've got funny ones like “BpscBulletProof”, obscure ones like “MsoGelIInsertSortPx”, and classes like “MSOGRFXMLNS” (buy a vowel?).

Third, Office has wrappers for almost everything.  I started by writing everything in standard C/C++, and it all worked beautifully.  But that was a big mistake, because none of it worked once I tried to merge it into the code depot.  I wasted the better part of a week translating ATLSoap to CBaseHSUser, vector to MSOPX, CMap to LKRHash, RegQueryEx to MsoRegReadWz, CString to CMsoString, and the list goes on. 

Fourth, the wrappers are actually pretty neat -- until you have to debug one.  Good luck figuring out what the author's intention was for “const WCHAR* const *rgwzArg” or “MSOPFNSGNPX pfnSgn” (I couldn't make that up even if I tried).  The time I saved using a “convenient wrapper” is quickly negated by having to figure out why my memory keeps getting wiped out.  It's like that movie Memento, but with a lot more swearing.

I think that's enough ranting for one post, back to work.

OK, now this is getting ridiculous..

Last time, they tore apart the roof and put it at my front door. This time, they got rid of the door!

In it's place was a tarp that was stapled on all sides to the frame. The problem is, this is the only way out! Trapped inside, I mulled about, ate breakfast, checked my email, but still my door was not to be found. Figuring I had to leave for work, I eventually pried the tarp off and crawled underneath. None of the workers seemed bothered -- did they expect everyone to do that? Strange..

My roof, my roof, my roof is on ... the ground?

I don't really know what goes on in my neighborhood, mainly because I never make it to the 7pm home owner meetings.  One morning, I was awoken by a loud pounding that shook the whole room.  When I opened my front door, this is what I found:

Apparently, a huge pile of my roof was lying there -- about two feet high... I hope it doesn't rain this week?

Calling a web service from unmanaged code

Just wasted a few hours of my life with a seemingly trivial segment of code.  Spot the error:


   HRESULT hrInit = CoInitialize(NULL);

   CUserProfileWebService webService;
   webService.Execute();

   if (SUCCEEDED(hrInit))
      CoUninitialize();


I was getting an Access Violation when the application exited, which means I was trying to access memory that no longer belonged to me.  Turns out, the problem was due to scope.  The "webService" object doesn't fall out of scope until after CoUninitialize has been called, so it doesn't know to clean itself up until it's too late.  The fix is to enclose the webService variable in it's own scope, such as the following:

  HRESULT hrInit = CoInitialize(NULL);
  {
    CUserProfileWebService webService;
    webService.Execute();
  }

  if (SUCCEEDED(hrInit))
    CoUninitialize();

In this instance, “webService” will clean itself up immediately after the } curly brace. Of course, it took forever to narrow it down to these five lines of code, at which point I realized my mistake. *sigh*

When to bug someone for help?

Let's imagine a hypothetical scenario where a group with whom you have a dependency on assigns a bug to you, telling you it is not their problem.  And, let's also say that you had little familiarity with this code.  Would you:

  A) Spend an hour to generally understand the code, and then try to debug what was wrong?
  B) Spend an hour to generally understand the code, and then find someone to explain the specific problem to you?
  C) Find someone to explain the specific problem to you, then spend an hour to generally understand the code?
  D) Twiddle your thumbs until someone with a more vested interest in this problem takes it over from you.

I think the answer is, it depends.  All too many of us go with Option A, simply accepting ownership of the problem.  Sure, you will learn the most by debugging everything yourself, but it will take the longest amount of time.  Often times, you don't care about learning about this code and just want to hack through to find a reasonable fix.  This approach would only be appropriate if you want to own this code long term, and the debugging time is essentially a time investment.

Researching the issue first will allow you to absorb the most when you finally do talk to the expert, since you will actually understand what he's talking about.  But talking to the expert first will save you ramp-up time, and has the additional benefit that they may realize they can fix it in less time it takes to explain it to you, and just fix it themselves.  I feel it works best for cross-group collaboration to do your own due diligence first, except in cases where time is critical.

Finally, there are times when even thumb twiddling might be appropriate.  Sometimes, the bug is sufficiently complex that you need the issues surrounding it to bake before you can tackle your own problem.  Sometimes, time is the only way for the other group to see the light.  Sometimes, time will cause the genuine priority of the bug to emerge, when it is weighed against other issues for possible postponement, and stakeholders protest.  I find the right things usually happen when they are being addressed by the people who care about it the most.

Welcome ..

I am a dev lead at Microsoft, which means I write some code and lead a hardy group of engineers writing cool features.  I expect to write about software, engineering, technology, and the like.. but I intentionally named this blog "null or empty" because there's a 50/50 chance the blog stays exactly that.  The name is a reference to the commonly used .NET api, String.IsNullOrEmpty().  Anyways, let's start with a comic:

If you can relate to this comic, hopefully you will be able to relate to this blog.