The Honeymoon Is Over

I've been here at Microsoft for more than 6 months so I guess you could say that I've passed through the Honeymoon Phase. By now the initial joy and excitement should be starting to wear off and I should be settling into a monotonous routine.

Well I'm happy to say that it hasn't happened so far. I'm still learning a lot, including things like:

  • Shipping big products is fun. We get to think about cool new ideas and some of them we implement and some of them get implemented by other smart folks.

  • Shipping big products is hard. We have to worry about things like localization, corner case scenarios and crashes that smaller products just don't need to consider. All of this takes time and there can be periods of time where you're fixing strings or working in high-contrast mode.

  • Our debugging tools are cool. For most of the bugs I need to fix my primary tool is Visual Studio. It is a good sign that even working with less stable dogfood versions is better than using another tool.

  • Bug/Feature Triage is important. We have so many people using our products that all kinds of bugs are reported, from serious (crashes) to suggestion (please improve this feature by...). If we did everything that was asked of us, we would never have a stable version to release. However, triaging can be much more lenient in the early stages of development. Here we go through stages:

    • Code review - any change you make must pass a code review. The reviewer might say 'hey, why are we fixing this bug!' and it may not be accepted.

    • Tell mode - closer to a release our team leads will go along to a meeting (called a shiproom meeting) and they will say "hey, we're fixing these bugs". If a lead goes along and says "we changed the font size from 9 to 10 points" without a good reason there might be some raised eyebrows.

    • Ask mode - even closer to release, before a bug is submitted, it has to go to the shiproom and be approved. Usually there are only certain classes of bugs that will be approved (blocking bugs, localization bugs, etc.). It is important that this 'bug bar' is known so that developers/leads know whether to attempt to fix a bug or not.

      All of this means that the number of bugs we fix gets fewer closer to a release, which means the product has time to stabilize and be thoroughly tested. At the same time, more minor bugs get a chance to get fixed early in the release cycle.

  • Company Meetings are exciting. There was a lot of shouting, collective back-slapping and cool demos. It was amazing that 1/3 of a baseball stadium was all from the same company.

  • Seattle summers are great. There is so much talk about how rainy Seattle is, but over summer the weather is warm but not really hot and it doesn't rain all that much. Daylight hours are long and it is perfect for getting out and about.

I also like hearing about new features and products and being able to try them out before they're distributed to customers. Let's see how the next 6 months go.

Skip to main content