MSDN Magazine > Issues and Downloads > 2005 > January >  { End Bracket }: Joining the Team
{ End Bracket }
Joining the Team
Matt Pietrek


It's been more than a year since my words last floated across the pages of MSDN®Magazine. As readers of my blog probably know, my life's been interesting the past 12 months.
A year ago I was involved in my familiar routine working at Compuware's NuMega lab in Nashua, NH. Although I had often thought of working for Microsoft, I didn't think it was feasible since my young son spends most of his time in New Hampshire with his mother and I wanted to be nearby. But then a variety of events began to pull me towards Microsoft.
A good friend had recently joined the Visual Studio® team and told me wonderful tales of a developer's nirvana. Then I had a chance encounter with Don Box at the PDC 2003, where he asked "Why aren't you working for Microsoft?" Finally, there were the phone calls with Chris Sells that convinced me it could be possible to both work for Microsoft and see my son regularly. After the interviewing dust settled, I found myself saying goodbye to many close friends and leaving the East Coast for the Pacific Northwest where I am now happily ensconced.
Within the vast universe of Visual Studio, I'm working in the group responsible for some of the cool new features in Visual Studio Team System—specifically, the profiler, static analysis, and test authoring and execution pieces. I've worked most closely with the profiler team, doing both development on Visual Studio 2005 and investigating features for the next release, code-named "Orcas." As the development world moves to ever larger and more complex systems, tools that help the typical developer truly understand what's happening in a software system become more and more critical. At Microsoft, I have fantastic resources at my disposal to help make these tools a reality.
One of the most exciting things is how much more transparent the Microsoft development process is to the outside world. Key people across the company communicate directly with outside developers through blogs and other media. The attitude genuinely seems to be focused on showing why various decisions are made and being able to react quickly if it looks like we're headed in the wrong direction. Because developers at Microsoft are on the front line, we get to benefit from outside expertise as well as build a better user community. It's amazing to see the extent to which we are influenced by the expressed wishes of other developers.
Questions I get often now are "What's it like being at Microsoft after all those years of spelunking into Windows from the outside? Are you like a kid in a candy store?" The answer is both yes and no. It's perplexing to me that many people still think I focus heavily on undocumented topics. The reality is that most of my work and writing in the past five or six years was just exploring documented items that either needed more "big picture" perspective or which didn't have user-friendly documentation.
One of the great things about working in the developer division at Microsoft (which encompasses both Visual Studio and .NET) is that as new features and extensions are added, I can use them right away. For instance, in the .NET Framework 2.0, the Profiling APIs have more interfaces and methods with much more useful functionality (see Jay Hilyard's article in this issue of MSDN Magazine). Because I know that Visual Studio 2005 requires this latest version of .NET to run, I can use these new interfaces without worrying about supporting prior versions. The same goes for using the new Managed C++ syntax which makes .NET-based C++ code just as simple and even more powerful than C#.
The occasional downside to using these bleeding-edge technologies is that sometimes you bleed. There is an amazing level of coordination needed to keep hundreds of developers coding despite simultaneous major changes across the entire code bases of Visual Studio and the .NET Framework. Still, you get the occasional bum build that passed all the tests, but which still leaves you hanging because the one thing you need it to do isn't working. You need to be crafty and devise workarounds to keep moving forward.
As for having access to the source code, yup, I'm guilty of searching for my name to see how my articles for Microsoft Systems Journal and MSDN Magazine have affected the development of Windows® and Visual Studio. Incidentally, I highly recommend setting up an index server for your source base. It's a fantastic way to find things in a huge, unfamiliar codebase. While I could easily spend months and months poking around this way, the sheer volume of things I'm still learning, as well as keeping my little piece of the puzzle in good shape, keeps me plenty occupied.

Matt Pietrek has co-written several books on Windows system-level programming as well as the Under the Hood column for MSDN Magazine. Previously he was a primary architect for the NuMega/Compuware BoundsChecker series of products. He now works on the Visual Studio team at Microsoft.

Page view tracker