Office New Employee Training

I was able to attend "New Hire Training" for Office last week.  At Microsoft, all newly hired people go through a day or two of training to get used to Microsoft, get your card key/badge and general agenda like that.  Mark Russinovich talked about his experiences with that session here, and it seems pretty straightforward.  And if you haven't started reading Mark's blog, you should.  It is very good and he shows how to use many of the tools from Sysinternals to troubleshoot and identify problems with Windows applications.

In addition to the overall Microsoft orientation, each team at Microsoft has its own ways of doing things.  Office is no different and we have started an orientation session aimed at people new to the office organization who have been here from a few weeks to a few months.  I did not get a count, but there were probably about 2 dozen at the session I attended last Friday.

I was there mostly as a sidekick to the main presenter, and told to offer "amusing anecdotes" or "amplifying information" when appropriate.  Naturally, the day started with an amusing anecdote.  One of the new employees came up to me and asked if I remembered him.  I did, since we had met last fall when I took a trip to Microsoft Texas.  He pointed to the tablet I had (the Lenovo - I managed to resurrect the disk) and asked if that was the tablet.  Spooky - he had been reading my blog and remembered all the problems I have had with that machine.  We talked a bit and then got down to the session.

My introduction to everyone started with my tenure as a PSS call center technician for Windows 95.  Two things became apparent from that year I spent on the phones. 

1. All the stories you hear about tech support calls are true.  All of them. 

2. My last call I ever had started like this: "I have an Epson compatible printer which won’t print with Windows 95, and I am not going to tell you what model the printer is.  It is Epson compatible and that's all you need to know."  This call did not go well. 

The rest of the session went well.  We talked about the drive to finish Office, how we release the builds, burn the CDs and even talked a bit about ship parties.  The only amplifying information I could offer was based on communication.  My suggestion was to attend a triage meeting (those meeting we use to identify the bugs we need to fix and in what priority order).  What can otherwise be a somewhat mysterious process is made much more clear when you see the human interaction around the discussion and understand, as a tester, why a bug comes back to you asking for more information.  Once you are familiar with why the bug comes back, you can be more sure the next time you go through the process that you get the information which is needed to evaluate the fix.  As a single example, let's say you have a spelling check bug and a fix for it.  One of the questions asked will be "What is the performance of the fix?"  If the new code fixes the problem but takes 500% longer to run than the original code, everyone needs to know this.  I think this is another way of saying to be complete with your testing and evaluation, and communicate clearly with your results.  Seems very basic to me!

Questions, comments, concerns and criticisms always welcome,

John