Chapters 14 and 21 are available to preview at Wiley’s site. They are free to check out, so give them a look to see if the book would be helpful to you.

Cheers,

David

I’m looking at this site nhdnug.org and not even sure what I’m looking at yet. My eyes immediately find the line “High Speed, Low Drag…” and I’m thinking “what!? This site uses the same tag line I do for my presentation.” I thought that was pretty cool, but then just a moment later I realized they posted the abstract for my meeting with them up on their home page. How cool is that?

I really look forward to meeting you guys (North Houston .NET User Group)!

Do some research about the company and specific job you want to which you submit your resume. Look specifically at the job description and think how you best fit that job. Does your résumé sound like a good match? Ask a friend to review it for you.

In my last post, I suggested not using a shotgun approach to catching someone’s eye. This is where customization comes in. You may know 25 technologies, but most of them are going to be irrelevant to this job. Highlight the ones you know that are most relevant in your job history.

I realize customizing your résumé can be a fair amount of work. Is it worth it to give yours an edge? Another thing is that as a résumé reader, if I can tell the person didn’t care enough to target my company or open job, it makes me wonder if they would do what is necessary to drive for excellence in the job, especially around communication. Hard work and intelligence applies both before and during a new job.

As a closing note, if the company has a free email service it would be smart to sign up for an account there and use it as your contact info. A neutral email service is fine, but a controversial pairing could be sending an impolitic message.

One example is when people list a billion technologies that they “know”. I’m cynical about how well they actually know any of those things well enough to really put it down. It is usually more accurate to say they are familiar with them, and sometimes even as bad as “something I heard about once”. The shotgun approach of I-know-a-lot-of-things isn’t really impressive. In fact, if an interviewer happens to ask you about one of the technologies that they know really well and find out you don’t know squat, then that can be (and has been) pretty awkward in the interview.

Yes, I know it is nice to put in all the right buzzwords for résumé queries to pick up on yours, and the real challenge is distilling what you really know and finding a way to put that in consumable paragraphs of how you used that technology. A list of items means very little to me because there is no context. Give me the context, and I’ll find you a lot more believable and interesting as a candidate. What you are showing me is that you think about how you communicate and can do so effectively, not just giving me a bulleted list of things that might be relevant – which isn’t useful.

Well now that we’ve shipped Beta 2 of VS2010 I’m overwhelmed with topics and have been able to keep up a daily post on our team blog, and I’ve been doing it for about three weeks! That is a record for me, and it is becoming more of a habit. I don’t plan on keeping a one-a-day pace forever, but I’m hoping this experience makes it easier for me to keep up a regular pace.

Also, I’ve been using a netbook at home now which I find incredibly convenient. I’m online much more often in the evenings now, while watching tv and such. With the help of Windows Live Writer, adding a new blog post is trivial, so all I really need is a topic.

Cheers

Add to Calendar

April 9, 2008
10:00 A.M. Pacific Time
Additional Time Zones

From group to group at Microsoft, the role varies however.  It's not surprising when we have hundreds of different groups and needs in each group.  Some PMs are UI focused.  Some are extremely technical and design APIs.  The PMs on my team focus primarily on user scenarios, application interfaces, and feature prioritization.  They seek user feedback in a variety of ways to validate the designs.  Since we are a v1 product, we suffer the typical problem of having very little user feedback.  You often hear joke that MS apps reach their full potential on version 3.  A big part of that is learning how to get it right as far as users are concerned.  Sometimes we need 2 iterations of trial and error accompanied by user feedback to find out.  Our goal is to improve that v3 groundhog day.

Our PMs are doing some amazing work.  They have so many different groups of customers (or at least target customers since we don't have a TCM application available to buy yet) from whom they gather feedback.  They PMs spend a great deal of time talking to customers, doing presentations, sending surveys, going over data, coordinating usability studies, and meeting with user groups.

Hopefully, if we've done our job right our v1 product will be closer to perfect.  If so, we'll learn considerable amount from this process.  Some efforts will prove to be more helpful than others.  Regardless, talking to customers is the obvious first start to making a v1 product useful to the people who might use it.

In VS2008 we fixed that which is great for customers because it's much easier to record the web test file directly rather than having to switch to another tool.  No offense to the author of Fiddler2.  It is an amazing web debugger that one should have installed anyway.  I'm using it for debugging a for-fun app I'm writing on the weekends to download some special podcasts.

Anyway, the new question was when I parameterize the web server name, how do I change it to a temporary value for a one time execution?  This feature has been in since VS2005 and I tried it to make sure before I responded... but it didn't work.

I looked up the topic on MSDN and it turns out you have to prefix the variable.  I asked one of our web test gurus and he said it's always been that way, but I guess I forgot.

If your variable name is WebServer1, then at the command-line set the environment variable name to be Test.WebServer1.

e.g. C:> set Test.WebServer1=www.MyCustomServer.com

Here's the direct link to the help topic: msdn2.microsoft.com/en-us/library/ms184806.aspx.

I did a search for these names to see what has already been published.  MS employees have already blogged about the personas, and some critics have come out against them.

A brief review of some of the criticism seems to be based on a misunderstanding of them and how they are used.  I'm not writing this to defend them, but it does bother me that the basis for the dislike is founded on falsehoods.

My understanding of the personas is that they represent work styles.  For instance, there are people who like to open the code editor and just start typing.  They use Intellisense to discover new features and learn by trying.  Others like to read up first and understand all sides of a technology before trying it out.  Chances are all of you have tried both methods at one point or another, though over time you probably trend towards one or the other.  Neither method is wrong or better.  They just "are" and it's important for us who are implementing new features to recognize that both work styles are common.  Customers expect both styles to be supported by Visual Studio.

If you want to know more about personas or the controversy around them, here are a few links to start from.

• www.bbits.co.uk/blog/archive/2004/01/15/167.aspx
• www.builderau.com.au/news/soa/-Mort-Elvis-Einstein-headed-for-the-scrapheap-/0,339028227,339250281,00.htm
• www.nikhilk.net/Personas.aspx

What I want to talk about is how we, in TeamTest, don't find Mort, Elvis, and Einstein to be proper work styles to describe how a manual tester approaches work.  Our usability team interviewed a lot of target customers.  They watched people working, asked them questions, and even invited us in the product group to take turns with them getting to watch and talk to these target customers.  I got to do customer visits at Safeco in the U District, and another at Getty Images in Fremont.

The new persona is called Ellen.  Whereas the other personas focus on programming approach, Ellen is not about programming at all.  She does have an entirely different history and motivation as one would expect.  She is so different from the existing 3 personas, you can see why it was important for us to create a new persona to guide our feature development.

One example of how she has impacted our direction is in our decision to build a test case management solution outside of the Visual Studio shell.  We're simplifying the user interface (getting rid of many actions and tools that she won't need) and reducing the time to install.  We want it to be easy to use, providing appropriate amounts of guidance along the way to explain artifacts and activities, and fully support her mainline scenarios with the least amount of manual work to accomplish them.

If you've seen an early preview of our work, you can plainly see we haven't yet achieved the spirit I write about.  We are dreaming of it though, and we're laying the foundation to provide all of that with each step.  You've seen CTP 8 and 10.  Soon you'll see 12.  I hope you've seen great steps forward in each CTP, and I can't wait for you to see the post CTP12 stuff we're working on now.

It also benefits us a lot too!  We have specific customer feedback to drive decisions in feature development.  A lot of it is anecdotal, but still very, very valuable.

I wanted to share the ways my team and I regularly interact with customers.  You might have participated in one of the many ways, but not known other ways to get to know us and have an impact on feature direction.

The MSDN Forums are a place for people to post questions and comments.  There are many different forums for specific features in Visual Studio and other products.  My product team has two forums.  One is for Web and Load Testing, and the other is for all general Team Test issues.  Every member of our team spends some time during the week reviewing questions and posting answers.  We also encourage others in the community to contribute as well.  We try to touch each post within 2 days, and strive for an answer in 7 days.

About once a month, we schedule live chats on MSDN.  We'll recruit 2-3 members of each product unit (TFS, TeamDev, TeamTest, TeamData, TeamArch) to attend and respond live to questions.  Watch this blog and others for dates, times, and links to the planned chats.  The transcripts are posted later for those who were unable to make it, and I suspect for search engines.  (Interestingly, the last transcript posted seems to be April of 2007.  I'll have to follow up on that and find out if the latest ones are posted elsewhere or if they just haven't made it up yet.)

Blogging is primarily a one way communication mechanism, but it does increase the transparency of what is happening inside of Microsoft.  I prefer transparency, even though I realize we can't always have it in full due to IP, etc.  We use blogging to show off new features made available in Customer Technical Previews (CTPs), Betas, and final releases.  See David Gorena's post about our test case management features available in a recent CTP, for instance.  We like to get comments on the blogs about what you see, though we don't get nearly as much feedback as we'd like.  If we blog about something you like, ask us to do more.  If we blog about something you don't care about, let us know that too.  If you have more questions, we'd love to hear them and we'll try to respond in another comment or in a new blog post.

We interact with the community in other ways as well, but these 3 are the things we do on the most regular basis and with the most number of people.  If you haven't gotten to know us in any of the ways I've listed, give it a shot and let us know how we can do better.

Blogs of interest:

blogs.msdn.com/vstsqualitytools

blogs.msdn.com/slumley

blogs.msdn.com/dhopton/

blogs.msdn.com/edglas/