by Michael S. Kaplan, published on 2008/06/11 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/06/11/8590844.aspx
The source of the main title is an inside joke I am probably not going to ever explain within the blog. Regular readers are encouraged to use their imaginations. :-)
It has been quite a while since I first blogged in An opportunity to start down the right [long ]path about the work in the .NET BCL to take a stab at the MAX_PATH issue, which BCL developer Kim Hamilton has now finished in three parts:
As a by-the-way, you should note how the BCL Team Blog currently links to this Blog (even though I am no longer even a virtual member of the BCL team except maybe in some cute "honorary" sense) but not to Kim's, when she is a core member of the BCL development team, an oversight which seems so improbable as to be worthy of the term kimpossible. :-)
Kim is now a friend, who I put in the same category as a small number of other friends (including Cathy) where my original interaction with them had me flipping the bozo bit within minutes.
I'll explain why in both cases:
In the case of Cathy, it was over eight years ago when I was a contractor and I had a client who wanted some specific locales and due to their LCID-based resource loader wanted some official LCIDs -- which she refused to assign at the time. Thus my initial "introduction" to her was by email and had me thinking of her mentally as "the <unspeakable term> who wouldn't give me my LCIDs" which is probably even a bit worse than the bozo bit.
In the case of Kim, it was just a couple of years ago and a brand new MS developer was jumping in to the long path discussion full of fire and vinegar about wanting to try to work out potential solutions to the MAX_PATH problem, something I am usually cynical enough about (even moreso than usual) to find anyone eager in the space to be worthy of their own bozo bit subcategory. Since
- I had never met her, and since
- Kim is actually a rather gender-neutral name, and since
- there are more male developers than female developers at Microsoft
I actually (mistakenly) assumed that "Kim" was male (an assumption not corrected until much later), and thus mentally thought of "him" as "the <even more unspeakable term> who wants to solve the MAX_PATH problem before I even have the chance to get any older" (since her first mail to the discussion alias about MAX_PATH was roughly nine days before my birthday!).
Anyway, it was not too long after my initial impression (in both cases) that I quickly ended up flipping the bozo bit off when I had the opportunity to find out that they both really did know their stuff, were careful and precise, and cared about the right results for customers, and were both actually pretty brilliant in their respective fields.
My initial mistaken impressions were quickly corrected, before either had the chance to learn what those mistaken impressions were -- beyond whatever my tone in email implied, which probably was enough to pick up on. I should apologize about that, and I probably will to each as soon as they notice this blog....
As an interesting by-the-way, both of their initial impressions of me reportedly did not really suffer quite so much from the same problem, which would suggest I should not jump to conclusions so fast before I get all they data. Luckily they are both friends now so I have the opportunity to try and learn this lesson!
And as another interesting by-the-way:
I did finally end up seeing those LCIDs assigned (it was after I was no longer working for that client) and I did end up seeing the .NET Framework ship a version that did more to assist with the problem than any prior version had even attempted let alone been able to support (after I was no longer writing nearly as much managed code as I had been previously.
In my former (more cynical) glass-half-empty days both cases would have felt like problems that were only solved after I no longer needed the solution -- typical Microsoft in the eyes of a cynic....
But in my current (less cynical) glass-half-full days both cases feel like solutions based on intelligent thought, planning, and as formal implementation based on actual customer need -- typical Microsoft in the eyes of a Microsoft employee who appreciates colleagues who have proven they what they're doing. :-)
If I have manged to bore you with this blogging blather (blother?) and you are actually more interested in the long path issue, you will probably find it is especially interesting to look at Long Paths in .NET, Part 3 of 3 and the comments to it, where you can find a great summary of what was done in the latest version of .NET and why. Highly recommended, for the information, the praises, and the critcisms.
It is review time though I don't know exactly how to give the not a bozo feedback for either in a way that there respective managers would find it to be in any way evidentiary. So hopefully its the thought that counts!
This blog brought to you by ⃥ (U+20e5, aka COMBINING REVERSE SOLIDUS OVERLAY)
BCL Team on 7 Jul 2008 9:16 PM:
Thanks Michael, I'm happy to have it on public record that I'm not a bozo. If the question comes up in the future, I'll just point them to your blog. :)
Yes, I can come across as overly eager, but <soapbox> we need to be getting worked up over problems like the MAX_PATH limitation. This is becoming increasingly restrictive and the "our hands are tied" resolution is unacceptable from a user perspective -- they shouldn't have to care about the internal issues such as Win32 restrictions. </soapbox>
I posted a part 3 redux to clarify questions from original part 3. See here:
Michael S. Kaplan on 7 Jul 2008 10:17 PM:
I noticed the issue with the BCLTeam blog not having a link to yours is still not fixed -- maybe you could use this "non-bozo" proof to indicate this is a good idea? :-)