The Moth

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!

Tip #1 – datatips on comments
One of the coolest debugger features introduced in VS2005 was DataTips (grey editable, navigable tooltips on steroids that also become transparent when you hold down the Ctrl key). Did you know that you can get data tips for commented code? At first this made me raise an eyebrow, but I can see how for some piece of code I may always need to inspect some other variables quickly and do not want to have to enter them in the watch window manually or navigate to the required area from existing variables that do exist in code. Here is a screenshot that shows this feature in action:

Notice how the datatip appears after highlighting a variable that is in a commented area of the editor (my highlight is set to yellow).

Tip #2 – save output window
In Visual Studio many times we need to transfer the text from the Output window to an actual txt file. Dunno about you, but I always selected all (Ctrl+A), copied (Ctrl+C) and then pasted (Ctrl+V) into a notepad instance that I always have running (Alt+TAB). It turns out that there is a direct way of saving that output to a file. Simply hit Ctrl+S (or invoke it from the menu item) once you've given focus to the Output window – nice!

What cool debugger features do you like in Visual Studio (or would like to see)?

When most people's brains first light up on why parallelism is the next BigThing, some jump to the conclusion that Moore's law is over. Let's clear that up below.

All of you know Gordon Moore's law which boils down to the prediction of

"the number of transistors on a chip will double about every two years"

In the last 30-40 years the previous prediction has manifested itself in clock speed increases and that is what has tricked most of us to associate Moore's law with CPU speed.

So, now that chip manufacturers cannot make single CPUs any faster (well, they can, but they can't cool them down enough to make them useful), they are resorting to having chips with multiple cores, which we are terming the manycore shift. The manycore shift has a profound impact on developers (especially those programming for the desktop client) in that their software now has to learn how to take advantage of parallelism.

So if you followed the logical flow so far, you'll conclude that Moore's law is still alive: we are still getting more silicon, but it does not translate to increased linear speed, but rather to parallel "engines" that your software must learn to utilise.

I am glad we cleared that up :)

One of my pet peeves is ensuring that whenever there is code that explicitly creates a thread, to always have an accompanying statement that names the thread. This is invaluable in debugging. With managed code, it is so simple, just one extra statement to set the thread's Name property (which you can only do once at runtime, of course).

This is such a useful thing to have when debugging, that in VS2008 the ability was added to name threads after execution had started. The idea there is for naming Threads that you don't control but still need to easily identify for debugging purposes. The name does not persist cross debugging sessions and indeed it is not used at runtime by anything other than your... eyes. I describe this feature as part of my video on all the new VS2008 threading enhancements (watch minutes 06:00 through 08:20, although I recommend the full 15 minutes).

At the OS level the ability to have names against threads is not supported (but you can use nice HEX ids to assist with your debugging ;)). Recently I discovered that there is an old trick (or hack IMO) that you can use with certain tools (inc. Visual Studio) to set names on native threads too. To get the details visit this short How To on MSDN. I did a quick search and discovered two more places on the web where this is described. One is on codeproject which is blatantly lifted from MSDN but it adds a couple of screenshots. The other also points to (an obsolete place on) MSDN and adds a bit more detail.

In short, for my managed friends: Search your code base now for the string "= new Thread" and for every match that you find, verify that you are also setting the Name property. You'll thank me later.

Yesterday a new 1-hour video interview on C# 4.0 was posted on channel9.

At some point the question is posed to Anders:

"What are some of the big issues that you are thinking about for the future?"

and Anders' reply (ffw to 39:56) identifies concurrency as the #1 thing:

"Concurrency is by far... profoundly changing... Moore's law... we've been ignoring concurrency because we could... now we can't... it is a damn hard problem..."

My favorite quote comes at 45:13 and includes hand gestures too:

"It is foolish to think that somehow we are going to be able to pepper concurrency on your code and you wouldn't need to modify anything in your apps today for them to run concurrently"

For the stuff in-between and to get the complete picture, watch the video.

As I did last year, thought I'd share that today (or yesterday depending on where you are) is(was) my 34th. I'll always remember this day as the day I received my SSN (progressing nicely thru the unordered list).

The goal: to withdraw some cash from one account and deposit it to another. How hard can it be? Isn't ATM user interface design an established known thing? Apparently not, as I found out...

I walked up (with a helper friend) to a cashpoint (the "hole in the wall") which had a big colour screen with buttons either side of it and more buttons in a keypad below. The screen rotated through some adverts and included no instructions as to what do: I inserted my card to make a withdrawal. Nothing happened. We both stared at the screen and start pressing some buttons – nothing. Eventually she went in to the bank to ask for instructions while I continued tapping on the screen and buttons for a little longer. I got bored so withdrew my card... and after a couple of seconds, guess what? It asks me for the PIN number! Wow! You have to pull the card out in order for it to operate... good thing I didn't walk away immediately as the next person could have come along and played "guess the PIN" without ever getting hold of my card! Anyway, in the end the withdrawal succeeded and I had $500 in $20 denominations which is what it gave out. Next step: deposit that cash into another account.

I insert the other card, nothing happens but now I know the trick so I pull the card out and I get prompted for the PIN (after a brief delay). It asks how much I want to deposit. I enter the amount of $500. It dispenses an envelope and instructs me to insert the cash in the envelope and stick it back in the slot; it states that the envelope must not contain more than 10 banknotes! How am I to deposit $500 that it just gave me in 20s by using only 10 notes?! If that is its limitation why didn't it state that before asking me how much I wanted to deposit? This is yet another example of getting the steps in the wrong order. Anyway, since I couldn't find a cancel button (or some other Ctrl+Z option) I put $200 in the envelope and stuffed it in the slot. It gave me a receipt thanking me for depositing $500 :-) By this stage, the person working at the bank comes out and after hearing the story says: "Yeah that happens all the time, I'll correct it on the computer". Sigh.

Why do we put up with such systems? I don't think we'll advance our profession as long as users have already decided to tolerate the crap we serve them.

It has been a week since I used a one way ticket to move from the UK to the USA. Closing down my life in the UK was a strainful experience and now I need to open a new one in the US.

There are tons of things to do in order to settle in – it is what I call "getting a life". I am sharing this list below partly for my tracking, partly because it may be of interest to anyone else going through the same relocation and partly so those of you that interact with me in person know where the stress is coming from:

1. Rent a mailbox for a year (redirecting mail from UK)
2. Move into temporary accommodation for a couple of months
3. Rent a car for a month
4. Communicate with legal parties to finalise the L1 Visa process
5. Get acquainted with area e.g. grocery stores, how to drive to work etc
6. Receive the AIR shipment of personal belongings (10 large boxes) and unpack
7. Get a new mobile phone (number + device)
8. Open a bank account
9. Apply to get pre-approved for a mortgage
10. Start house hunting, make offer, buy, move (this can be a whole list on its own)
11. Get a Social Security Number (SSN)
12. Get a credit card
13. Have driving lessons
14. Take driving written test (after learning some new road signs)
15. Take driving test and hence driving licence
16. Buy car (do this via a loan in order to build some US credit history)

And last but not least:
17. Settle into new job / role

Another reason I am sharing the above is so those of you staying tuned on the RSS feed know why it is going to be a quiet summer... I can't wait to get through to the other side of all that and start sharing with you the coolest stuff coming in the next version of Visual Studio ;)