color cycle (slow)

Kistaro Windrider, Reptillian Situation Assessor

Unfortunately, I Really Am That Nerdy

Previous Entry Share Next Entry
"Fix", the other "F" word
a look of abject horror, yikes
kistaro
So I've been busy recently.

This is my last week of work. Tomorrow is my interview to retain the position I had; Friday is my final presentation to the VP in charge of COSD internships, then my team is taking me out to lunch. I'll actually have a full week between finishing work and going home- that gives me time to pack up my stuff and figure out how to get it sent home, but I've also got plans to use the intern shuttle that's intended to take interns to work just to go to Overlake Transit Center and then spend all day exploring the city bus system (with a careful eye on the clock to make sure I can get back to Overlake before the last shuttle leaves). That might give me a way to end-run around how bad the local bus service out in Sammamish is...

Anyway, yesterday was a frantic ten-hour day. Today is my presentation to the head of the product group I'm in (two levels above my manager), and yesterday, I discovered a showstopper of a bug. I tried to fix it, but I had to go leave to catch the last shuttle to my apartment before I could fix it. Instead, what I managed to prove was that my first "fix" actually exacerbated the problem. But now the failure is so reliable, predictable, and isolated to about three lines, I'm getting convinced that this isn't my bug, but I found something wrong with the .NET Runtime Environment.

At least I was already planning on coming in early this morning since I have my interview at 8:30 AM tomorrow (and I needed to fix my sleep schedule for that). I've got until 5:00 before my demonstration to Siva, and I either have to fix my bug by then or prove that it's .NET, with enough documentation for anybody to replicate it and the .NET team to fix it.

  • 1
Microsoft products with bugs? NEVER!

Yeah, I'm not entirely surprised to have encountered something like that. I've spent the morning isolating exactly where the failure occurs, and I've basically proven that there's something rotten in the .NET API and it's not my fault; there are already known bugs in other parts of the PerformanceCounter (and related classes) so it hardly surprises me that I found another one.

But I couldn't find any references to the exact failure I've discovered when I did a Google search. Either I overlooked it with bad search terms, or I'm the only one who's having this problem.

So what I had to ask myself is, since this API has been out there for years, is it really plausible that I'm the first one to run into it? Contemplating the API and the unpleasant things I've been doing with it, my conclusion is "yes" because the .NET PerformanceCounter API, to do the nasty things I need to do to it (add a new Performance Counter to a PerformanceCounterCategory that already exists) require the complicated corner parts of this API. Those complicated corner parts are a festering pile of shit. If I wasn't being paid (and paid well) to do it, I wouldn't touch them with a ten-foot debugger.

I've talked to several other people about it, and my supervisor isn't upset that my API doesn't work since I really have proven that it's a .NET bug- instead, he's impressed by my diagnostic ability and my persistence in proving where the error is. So I guess I can stop worrying about it now.

Related to nothing, I still think that userpic is really cute.

Well, it's good that they recognize your abilities or whatnot and not gotten aggravated at you for not making it work anyway, or something. Heh. Thinking outside the box and all that. Or something. :P

And thanks, I think it's cute too. Granted, I've been toying with yet another idea again, but I have to see about when I can get it drawn.

I'm highly amused by your description of the "complicated corner parts" of the API and how little you like messing with them.

  • 1
?

Log in

No account? Create an account