Catch the "Parallel Programming in .NET 4.0" session online

Thu, October 30, 2008, 09:15 AM under Events
Things have been crazy busy leading up to PDC and now it is finally drawing to a close and I look forward to my flight back to Seattle from LA.

Those of you that did not have a chance to attend my TL26 session can watch it online (or download it from) here.

If you did attend my session, please make sure you fill out the evaluation form by clicking on the ()icon next to the session on the PDC Timeline (Day 3 at 10:30AM at the bottom).

If you are attending Tech Ed EMEA in 2 weeks, I'll be repeating this session in Barcelona so don't watch it online ;-)

Video on Parallel Developer Tools

Fri, October 17, 2008, 06:24 PM under ParallelComputing
Last week SeanNo, SteveTei and I spent 40 minutes with Charles from channel9 discussing and showing what we are working on in PDT for Visual Studio 2010 for enhancing the debugging and profiling experience for parallel programming.

Watch the ch9 video here.

Add "Parallel Programming in .NET 4.0" to your PDC schedule

Fri, October 17, 2008, 05:59 PM under Events
The (really cool) schedule builder on the PDC site now includes timeslots for all sessions. Come to mine on Wednesday 29 October at 10:30 AM (straight after the keynote) in Petree Hall CD.

Email Rules

Sun, October 12, 2008, 07:20 PM under Communication
Back in my MVP days before joining Microsoft I used to help out a lot on newsgroups and forums so I wrote a piece about Newsgroup Rules. The time has come to do the same for Professional Email.

Many of us work in organizations where email is the primary mode of communication dominating every other medium. For example, in Microsoft, I have yet to hear my desk phone ring and I easily send around 300 emails per week and that is far less than the amount I receive. With email being so prevalent, I would have expected every person joining large companies to immediately get training on making best use of their email client e.g. Outlook. If everybody followed a simple set of rules, we could reduce the amount of emails on the wire, which is a good thing for everyone’s time involved.

Below are the rules that everyone in my (fantasy?) world would follow. I break it down by the fields we can fill in when composing or replying to email:

1. KEEP the explicit recipient list short. The more people you add, the less chance you’ll get a reply. Who is it that really must be on the TO list? Who is it that you are expecting to take some action based on your email?
2. MOVE to CC if it is just an FYI. If you are not expecting a reply from me and you are not expecting me to take some action, I should be on the CC list not the TO list._
3. ADDRESS the TO people. If I am on the CC list, don’t talk to me – talk to the TO people. You are sending it to the TO people, not the CC people. Also, really do address the TO people: if you cannot imagine reading out loud your email to *everyone* on the TO list, then you have your TO list wrong.

4. MOVE to TO if expecting an action. If you are expecting an action/reply from me, I should be on the TO list, not the CC list. If you leave me on the CC list don't be surprised when I don’t reply promptly (because your email has gone to a folder that I empty every week).
5. REMOVE if it is not even an FYI. If I don’t even care about the topic of your email, remove me from the CC list. Don’t assume I am interested in your email to start with.
6. NOTE that when you hit Reply, Outlook cannot read your intention and make the changes suggested by the rules above: you are allowed to move people between the TO and CC fields while a thread is ongoing.

7. DO NOT USE. Ever. Never!
8. REPLACE with two actions: Reply to the people on the TO/CC field and additionally FORWARD to the people you wanted to place on the BCC field.
As an aside, if you BCC me, your email will end up in my DELETED folder due to a rule I have setup.

9. HAVE one. Take a moment to summarize your email in a few words on the subject. If you can’t, then your email probably serves no purpose.
10. KEEP short. There is a BODY field for your diatribe, keep it out of the SUBJECT field.
11. BE specific. Subjects such as “Bug”, “Question”, “Visual Studio”, “Your blog” etc are not good subjects on their own. I should be able to distinguish your email from other emails just by looking at the SUBJECT.
12. USE hints at the start of the subjects. For example: "Action Required: xyz", "FYI: xyz"
13. AVOID changing the subject unless it is a new topic. Don’t even correct a spelling mistake (it breaks the thread).
14. DO change for new topic. If the topic has changed, then the previous rule can be broken BUT: consider keeping original in parenthesis e.g. “New topic (WAS: old topic goes here)”.

15. KEEP short and small. Short URLs, small size of attachments. If you can’t keep to the previous two guidelines, group together the URLs/Attachments on an intranet site and just point to that.
16. LIMIT overall items. The more URLs/ATTACHMENTs you send, the less likely I am to look at any of them.
17. PROVIDE context. Why do you think I’d open your email attachment or click on your URL if you don’t tell me something about them? Don't assume I am interested.
18. AVOID uncommon extensions. I don’t care about the technical merits of TAR vs RAR vs ZIP. Zip is what most people have installed – use that.

19. KEEP short. When your email signature is longer than your message, you know something is wrong. Generally, a single line of text is more than enough.
20. FORMAT as text-only. In particular, no images or anything that would appear as an attachment in a text-only client.

21. AVOID fancy backgrounds. White works.
22. AVOID funky fonts.
23. DON'T USE shortcuts as if you are writing a TXT or IM message. For example, "R u going 2 rpl to that eml?" should be "Are you going to reply to that email?". You are exchanging emails with professionals here, not your family. Using standard acronyms (e.g. LOL, AFAIK) can be OK though.
37. DO NOT UNDERLINE unless it is a URL you are underlying. In this internet age, people try to click on underlined words. Instead if you want to emphasize something use highlight, boldness and italics.

24. AVOID long text. There is a threshold for the length of an email after which nobody reads it.
25. HAVE structure (paragraphs were invented with good reason).
26. USE spelling and grammar tools.
27. CONSIDER using bullets.
28. CLARIFY the purpose of your email: Are you blocked and need someone to unblock you or looking for an answer to a question or for someone to take action or just reporting some status or sharing some information etc.
29. ANTICIPATE follow up questions. If you are going to send me an email saying that "it doesn't work", you can bet that my reply will be "in what way doesn't it work and what have you tried already?". Anticipate and provide that info up front.
30. VERIFY that you really need to send the email. Are you looking for information that your favorite search engine can provide you with? Does the answer already exist in your inbox? Does the information exist on your intranet?
36. DO NOT INCLUDE a body if the subject says it all. Write <eom> in the body for “end of message” or at the end of your subject. If the subject says it all and the attachment is valuable, include, <attached> or <attached, eom>

31. DO REPLY within 24 hours to any email that lists you and only you on the TO line. Try to do the same for emails that include you on the TO line amongst others.
32. SET expectation of when you will have a final reply or an update, if you cannot get the answer within 24 hours.
33. SETUP Out Of Office auto-replies when you are not checking your email as often as usual.
34. READ your composed email before hitting SEND. 1% of all emails I compose do not get sent after I re-read them and 25% I tweak for clarity after reading them. I bet you'll have similar experience if you do this for emails you compose.
35. DON'T SEND while experiencing negative emotions - anger, fear, grievance, annoyance, etc. Only send the email when you can calmly and professionally review your thoughts first.

Finally, specifically for Microsoft colleagues that use our internal DLs:
a) Realize that even if you are not a member of the DL, you will get a reply to your question. The only way you wouldn’t, is if someone explicitly removed you from the TO field which I have never seen happen. So stop asking: “I am not a member of this DL please Include me in the reply”.
b) Stop stating: “Remove/Add me to this DL”. One word for you: autogroup.

Do you agree/disagree with any of the above? Have you got any other guidelines that you would add to the list?

Parallel Extensions are part of the .NET Framework 4.0

Sat, October 11, 2008, 01:59 PM under ParallelComputing
There have been two CTPs for the "Parallel Extensions to the .NET Framework 3.5" (readers of this blog will remember November and June).

Aligned with the recent announcement about .NET 4.0 coming, the pfxteam announced yesterday that Parallel Extensions gets rolled into .NET Framework 4.0.

This is great news because it means that there should be no concerns from a deployment, support and future versioning perspective: it is the same as the .NET Framework :-)

IMO it is a misnomer now to refer to these bits as Parallel Extensions since they are now part of the core: mscorlib.dll and system.core.dll. It is however still relevant to use the terms TPL and PLINQ, the two major components and that is what I did for the abstract of my PDC session.

Parallel Tasks window

Wed, October 1, 2008, 02:31 PM under ParallelComputing
Previously I asked about properties of Tasks that you'd like to see when debugging and suggested some:
[...]which ones are not scheduled yet [...], which ones are Running and which ones have run a bit and now are Waiting [...]. [...]quickly see the call stack of each Task and also which thread it is executing on. [...]parent-child relationship between Tasks.
Rather than talk about it in totally abstract terms, how about having a few mock up pictures.

After hitting a breakpoint, below are 2 Tasks running and 4 that are waiting (in our example there aren't any Tasks that are scheduled in a queue and not run yet). Then on the picture on the right, we switch to parent child view, we can see that four Tasks are actually waiting for their child tasks to complete:

In this different example below, we grouped by the Location column so we can see that 3 Tasks are running in method H of class P, and 1 task has at the top of its stack the method C of the same class. We also see the IDs of the underlying threads running those Tasks:

I can't wait for you to start working with the Task-based APIs, so you can provide feedback on what supporting tools you'd like to see. Hopefully the Parallel Tasks debugger toolwindow is a good start.