Six Months At MSFT

I got the results of my review on Monday then talked to my manager and his manager about my career goals. The good news is that I've done well enough not to worry about being fired for all the Slashdot and K5 reading I do at work when I should be working. :)

I was talking to a friend of mine who used to work at Trilogy before the meltdown and he commented about how rare it is for IT and software people to think about work in terms of career and not job since the meltdown began. I guess that's one of the things I like about working here. It's one of the few places where I where the work options span the entire breadth of computer science all under one roof while allowing one to still maintaining an upward career path without having to worry about hitting the technical person glass ceiling [and have to switch to management].

My favorite phrase since I started working as an SDE/T (developer/tester) and fielded questions from people about why I didn't try to become a developer or program manager is "I set the Quality Bar". The people most directly responsible for the quality of a piece of software are the testers. They also typically have more knowledge about the product and how it all really works together than the devs and the PMs. So if our implementation of the XQuery type system sucks, blame me.

The one thing I've liked the most about my past six months is quite the cliché. I've liekd the amount of freedom and lack of micromanagement I've experienced. I think it's similar to what people call empowerment. Joel Spolsky described it best in Command and Conquer and the Herd of Coconuts. At Microsoft you don't work on a technology or an aspect of a product, you own it.

#

Aaron Schwartz on Standards and the Law

During my daily morning blog stroll I came across an entry by Aaron Schwartz entitled Standards and the Law where he opined

Is the W3C illegal? While reading some relatively unrelated things I found a message where djb discussed US requirements for standards bodies. The court ruled that they must "prevent the standard-setting process from being biased by members with economic interests in stifling product competition". I wonder if you could make an argument about this and Microsoft and XML Schema...

Clark v. W3C, here we come. Somebody call the EFF.

I assume he was partly joking given the smiley at the end. I've talked about the issues with W3C XML Schema in a past diary. Basically it's a case of too many cooks spoil the broth. Going back and reading the W3C XML Schema requiremnts one can't help but notice that this one standard was supposed to satisfy relational DB vendors, OO databse folks, OLAP, programmers, e-commerce needs and publishing. Given that each of these constituencies has extremely different needs, it's no wonder that few are pleased with the resulting compromise.

What has begun to exasperate me is that some people have muttered that the big vendors (i.e. we of the Borg) made the recommendation complex on purpose so as to prevent smaller entities or Open Source developers from implementing it. Before I started working here I used to think the same thing as well. However the reality is quite far from that.

The fact is we don't have a 100 people implementing each W3C recommendation. Creating specs so complex and formal that it takes a P.hD to interpret them makes our job quite hard and expensive all around. Our users don't understand the technology, testers aren't sure what to test and the devs aren't sure how or what to implement. Given that the entire company is in the midst of a XML Web Services push I actually would like as many people as possible to implement W3C XML Schema because the goal of this is interop not lock-in.

We dislike the complexity as much as everyone else. Just look at how simple the MSFT XML schema proposal originally submitted to the W3C is compared to what ended up being created by having a bunch of P.hDs from umpteen different companies hash out the spec.

However we grit our teeth, go ahead and develop kick ass implementations anyway. It's just annoying after arguing with the working groups, our reps and trying to ease things for our users having MSFT blamed for how the recommendation turned out.

It's not always Microsoft's fault.

#