There are a lot of Microsoft bloggers, literally thousands of them. When I first joined Microsoft I wasn't sure who to read. I've gradually built up a list based on interesting product and feature announcements and people I've met. Here they are:

Profiling

• Our Team Blog
• IanWho's Blog. Written by a fellow dev on the profiler team, Ian has probably written the most about profiling across the team.
• joc's bLog. Written by my bosses' boss.
• mgoldin's blog. Written by a senior dev on my team. Find out about the difference between different types of samples etc.
• My Code Does What?!. A relatively new blog about profiling by another fellow dev.
• scarroll's Blog. Written by my boss.

Technical

• bharry's WebLog. Written by a Technical Fellow (read more about this) with a huge amount of experience who has a big focus on TFS.
• Greggm's Weblog. Written by a senior dev on the Debugger team. Has many advanced debugger tips.
• Mark Russinovich. Mark wrote some cool Sysinternals tools and now blogs some fascinating posts about his investigation into problems he finds everyday just using his PC.
• Rico Mariani's Performance Tidbits. Written by a senior Microsoftie who has been here for a long time. Gives tips for analyzing performance and provides guidelines to use in writing .NET code.
• ScottGu's Blog. Find out about LINQ, ASP.NET AJAX etc. etc. This blog has many examples including screenshots and source code.
• Somasegar's WebLog. As the corporate VP of DevDiv, Soma covers a lot of Visual Studio features and other developer tools.

Other

• Microsoft International Tech Jobs. I keep an eye on Microsoft's international opportunities here.
• Microsoft's JobsBlog. Discusses many aspects of Microsoft's recruiting. Covers the Vancouver office developments and has tips for prospective Microsofties.

That's just some of the Microsoft blogs I read. Are there other 'must-reads' that I'm missing?

I've been thinking about what some of the most important tools are for me while coding. Here's a few:

• Good IDE - syntax highlighting, integrated builds, source control integration, search facility, debugger and profiler built-in. I use VSTS.
  
• Source control/bug tracking system. I use TFS (typically a dogfood version of TFS).
  
• Windows Task Manager.
  
  I use task manager to:
  - View CPU usage
  - Kill processes
  - Start a new explorer.exe if I ever kill explorer.exe. Do this from the Applications tab.
• Process Explorer.
   
  I use Process Explorer like task manager, but it can also:
  - Find what process has a handle (e.g. a file) open. This can be handy if you want to delete a file but a process has it locked.
  - Find out what DLLs a process has loaded
  - List the environment variables for a running process
• Process Monitor
  
  I use Process Monitor to record file, registry and process activity. This is very useful when debugging issues in complex programs like VSTS which have a lot of registry interactions.
• DebugView
  
  Display debugging output from programs without having to attach a debugger. This is very useful if you want to run your program outside a debugger and still want to see all those debug prints.
• Media Player. I like to listen to music while I code.
  
• Outlook. It is somewhat sad that I spend a fair percentage of my day reading emails, scheduling or checking up on meetings and writing notes in an Outlook journal, but I do and so I have Outlook open all the time.
• Internet Explorer. I need to use MSDN a lot and do web searches. I also read RSS feeds of relevant blogs with IE.
• Regedit.
• Remote Desktop. I work on different machines pretty regularly and Remote Desktop makes switching between machines easy.

The Visual Studio 2010 MSDN documentation includes some more detailed examples (including screenshots) than previous versions. Here's a decent intro to profiling:
Beginners Guide to Performance Profiling

Join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.

We will be holding two sessions:

Join the chat on Wednesday, December 5th, 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

                -and-

Join the chat on Wednesday, December 5th, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones

--- 

I'll be in the Wed 4 pm - 5 pm chat to answer any questions related to profiling. Another member of the profiler team will be online for the earlier chat.

---

With Visual Studio 2010 we want to make it clearer when you are profiling your application within the Visual Studio IDE. To accomplish this we added a new control which we call ‘Profiling In Progress’ or PIP, which we show when you launch the profiler or attach the profiler to a running application.

Our goal was to show something simple and lightweight while profiling and to make a few simple operations possible. PIP in VS2010 is shown below:

Currently profiling. Pause profiling. Stop profiling or exit the application to generate a report.

The progress/spin control indicates that the UI is responding and there are two links:

• Pause profiling, which changes to ‘Resume profiling’ when clicked. This has the same effect as clicking on the ‘Pause profiling’ button in the Performance Explorer.
• Stop profiling, which kills the application and finishes profiling.

After profiling completes, PIP changes to show that we are about to open the report.

Preparing to open report… This might take a while if your symbol server is slow or not responding.

I went to a meeting with Rico the other day and he showed us a few approaches he uses when solving performance issues. He is a performance engineer with many years of experience so it really was a case of watch and learn. This got me thinking about how people can best learn to use performance tools.

One starting point in this process is to consider my own experience learning a more mature dynamic code analysis tool - the debugger. Think back to the first time you ever started up a program running under a debugger. What was the first thing you did? My first debugging experience went something like this:

• Set a breakpoint at the beginning of main() - this was C/C++ afterall.
• Run the code in the debugger. Hey, it stopped. cool.
• Step through a few lines of code and inspect the values of some local variables.

Sit back and think that's pretty cool - maybe I'll have to use a few less printfs to work out what's going on with my program. That's pretty much it. Gradually I learnt more and more about things like:

• The difference between Step In, Step Over, Step Out, Run to Cursor
• The value of different types of breakpoints like conditional breakpoints, data breakpoints etc.
• The value of the Watch window. I'm still surprised by how much you customize the output to make it easier to find issues.
• The various other windows - threads, memory, etc. etc.
• Etc.

It took a long to discover some of these features. It took even longer to use them almost automatically while debugging.

Obviously the learning curve depends a lot upon the tool you use. Visual Studio tries to be more intuitive and easy to use than something like WinDbg, which is a command-line tool. Even with the ease of use of the visual debugger, you still need to know the typical debugging pattern (using breakpoints) before you can use the tool effectively.

Fewer people have used code profilers than debuggers and the tools are still less mature than their debugger equivalents, so it is harder for new programmers to profile their code than to debug it. In an ideal world we might have a 'fix my code' button or at the very least a 'highlight problem code lines' feature, but for now we need to develop patterns that developers can use to do this themselves.

What features would make profiling easier for you? Are we missing a fundamental concept (the equivalent of 'set breakpoint' in debugging land) that would make things so much easier?

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.

The GM of Visual Studio Ultimate, Cameron Skinner, recently gave a talk at Tech-Ed 2011 about Application Lifecycle Management. It is worth taking a look at if you're interested in some of the new features being created for the next release of Visual Studio, such as the Team Navigator, shown below: