The Moth

With the release of VS2008 the ability to debug into the framework source became possible (follow the link for my video on the topic). There is now a dedicated blog with instructions, links to forums and other relevant info, so visit it to learn more. They just announced the availability of sources for NetFx 3.5 SP1.

I only learnt about this featurette very recently (from a reader's comment) and immediately found a use for it – read on.

If you tried to debug the code from this exercise (still no correct answers to the quiz!), you probably found out that the variable corresponding to the Task that you want to examine is usually out of scope. You can look at the Threads window and try and map the Thread to the Task but there is another way: add once to the Watch window the expression Task.Current. When breaking in the debugger, switch between the threads in the Threads window to see the active/current Task for that Thread in the Watch window.

The only problem is that we have to tediously expand the variable each time to determine its Id, since the default display when the expression is evaluated is not useful ("{System.Threading.Tasks.Task}").

This is where the C#-only debugger feature comes in: Make Object ID, accessible from the ContextMenu in the Watch window. Once you break in the debugger, Make Object ID for the Task.Current, then switch Threads and do the same for the other. Now you can distinguish between them easily due to the appended {1#}, {2#}, and you can add a Watch directly to the objects in memory:

This is a neat little feature and even more useful for other scenarios where there is a need to distinguish between 2 or more identical-looking objects in the debugger.

Steps:
1. New C# Console Project in VS2008
2. Add Reference to System.Threading.dll (from Parallel Extensions June CTP)
3. Replace the entire contents of Program.cs with the following (overly simplified extract of a more complex piece of code):

using System;
using System.Threading.Tasks;

static class Program
{
  static void Main()
  {
    Task t1 = Task.Create(delegate
    {
      Task t2 = Task.Create(  // breakpoint #1
        (o) =>
          Console.WriteLine(o.ToString()) // breakpoint #2
          , "hey");
      t2.Wait();  // breakpoint #3
    });
    t1.Wait(); // breakpoint #4

    Console.ReadLine(); // breakpoint #5
  }
}

4. Insert a breakpoint (F9) wherever there is a comment.

Questions:
A. Without running the project, what can you predict about which breakpoints will be hit and in what order?
B. Can you predict at each breakpoint, which of the two variables (t1, t2) is in scope (e.g. if they were in the Watch window)?

Everyone close to me that knows I recently changed jobs keeps asking me what it means to be a feature PM (not to be confused with Product Manager which is primarily a marketing role). The Program Manager role is so complex I am having trouble explaining it. I am not ready yet, so I will revisit the topic in the future but someone once told me:

"a product needs developers to write the code and testers to test it. There are other things involved with shipping a product and the PM does those".

So far I can share that I spend 75% of my time in meetings. The funny thing is that I used to view meetings as a waste of time, but for the first time in my career I am actually having tons of useful meetings. The reason is probably because most of them are of the brainstorming variety (where by the end your creativity juices are just oozing all over the place) or of the unblocking variety (where at the end someone is unblocked and can do their job, which they couldn't do without that meeting having taken place).

Looking at it from a different angle it seems that there are several hats that a PM wears and I find myself alternating between writing specs, project managing, testing scenarios on the product, creating walkthroughs, threat modelling, writing demos/samples, liaising with sister teams, liaising with internal customers and, finally, preparing to imminently liaise with developer customers (both inbound and outbound comms, gathering feedback and sharing the vision) when we release it.

Some view the "drawback" of this role being that: you have tons of responsibilities which you can only deliver via a team on which you have no authority. Read that sentence again. I think this is what differentiates this role from others outside of Microsoft. I actually enjoy this because it creates a true team spirit. Because most new PMs seem to find this the hardest part, most experienced PMs focus on sharing tips on how to overcome this "hurdle". Today I found such a post that advises on the success patterns for PMs (with many good links).

The Professional Developers Conference (PDC) is held in October at Los Angeles, which is one of the reasons I am looking forward to be going there (as a teenager I was a huge The Doors fan), another reason being the party.

However, the main reason I am excited to be going this year is because I will have the opportunity to share with developers from around the world some of the cool things that our teams have been working on.

Parallel Computing has a very strong presence at PDC08, so follow the links to find out more:

1. A whole PreCon day of Concurrent, multi-core programming on Windows and .NET.

2. Four breakout sessions (click on the Parallelism [4] tag in the sessions list)

3. Even more on the final day of PDC, to be shared later...

Hope to see you there!