Category Archives: Microsoft

Why internal blogs don’t make it

Scoble wrote yesterday about the fact that even though there are a growing number of MS people with external blogs (enough to force the move off of GDN), there hasn’t been a commensurate number of internal blogs. In fact, I’d have to say that pretty much most of the internal blogs that I’ve read are a dismal failure, and I’ve dropped every single one out of NewsGator. Robert speculates that the problem has to do with discoverability and linking, but I think the problem goes deeper than that. Specifically, I don’t think internal blogs work very well because:

  1. External blogs make Microsoft people be more open and less insular in the way that they talk about things. Public blogs expose our thoughts to a pretty broad range of people, so we have to assume less and explain more. Internal blogs, on the other hand, allow us to make lots of assumptions about shared knowledge, meaning that internal blogs tend to be more dry and less interesting. Which, in turn, makes them less fun to write.
  2. External blogs expose us to people who don’t agree with what we have to say, to put it mildly. This provokes lively debate and interesting discussions in a way that is harder to replicate internally. I’m not saying we’re the Borg here, but there is a shared culture within the company that makes people a bit more decorous. Decorum also makes people, I think, less likely to rock the boat on internal blogs. This doesn’t make much sense since people inside the company read external MS blogs too, but there you are.
  3. It’s like the old Friends joke where the gynecologist says about his work, “It’s like being a waitress. When you get home, the last thing you want to do is look at another cup of coffee.“ Most of us spend our days talking to and emailing other Microsoft employees. The last thing we want to do is write the equivalent of another memo. It’s much more fun to talk to outside people.
  4. One of the big things that external MS blogs provide is information about what MS is doing. Internally, there are a lot of resources available to employees that often trump blogs. (Not that there isn’t room for improvement, as Scoble notes.) I don’t read Chris Brumme’s or Suzanne Cooke’s excellent blogs anymore because a good amount of the information they talk about is available in internal specifications. And if there’s something piece of information I can’t find, I have the luxury of calling them up or scheduling a meeting with them to get my questions answered.

I’m pretty skeptical whether internal blogs really will ever work. I’m more intrigued as to whether collaborative technologies like wikis can make a big difference. After I get back from some major vacation (more on that later), it’s something I’d like to explore inside of the VB team.

It’s good to know we are not alone…

Stan Lippman, a C++ guru at Microsoft has started blogging. His inaugural entry discusses one of the issues that their language design team faces in moving C++ to the CLR. Near the end, in a section entitled “The C++.NET Design Challenge,“ he says:

Literally, for every aspect of the C++ extensions to support .NET the question always reduces to “How do we integrate this (or that) aspect of the Common Language Runtime (CLR) into C++ so that it (a) feels natural to the C++ programmer, and (b) is easy to use in its own right under .NET. I like to call this the Janus face dilemma. (Janus is a two-faced Roman diety, the one turned facing towards what has just been, the other towards what is to be.)

As my entry title says, it’s good to know that we (the VB team) are not alone. Moving VB to the CLR was a major undertaking involving many, many, many dilemmas along these lines. Even though C++ and VB are two very different languages, I have a lot of empathy for what the C++ team is going through as they struggle with these questions. It’s not an easy path to trod.

Names changed to protect… somebody.

I’m reviewing VB runtime functions as I work on my book and I noticed that the VbTypeName function has a very odd parameter name:

Public Function VbTypeName(ByVal UrtName As String) As String

Huh? What’s that “Urt” thing? That’s just one of the five hundred names that was attached to what eventually became the Common Language Runtime (or CLR for short). URT stood for “Universal RunTime.”

As I think I mentioned when I was talking about codenames recently, the one thing you can count on at Microsoft is that there will be absolutely no consistency or constancy to names over time. I have no idea why that is, but it just seems to be that way.

C Octothorpe?

The “A Word A Day” mailing list reminded me of something one of the guys I used to work with would joke about when the C# team first came up with their name. The sharp symbol goes by many names, the strangest of which has to be “octothorpe.” (Just click on the link and search for “octo” to find the entry.)

I realize that I’m hardly the first person to mention this, but I’d never seen such an exhaustive discussion of the etymology of the word. Or a list of all the other names that # goes by. C hak? C gridlet? C square?

The horror! The horror!

Eric Lippert has started a new blog, and I think I’m suffering from some low-grade PTSD… Before I started working on Visual Basic .NET, I spent a year and a half in purgator… I mean, working on OLE Automation. (I’d moved over to OLEAut from Access because I wanted to work on language technologies and I figured OLE Automation was where it was at. I think a few weeks after I moved over, I had this meeting with some guy named Brian Harry about this weird project he was starting to write some new metadata engine…) Eric’s extended fantasias on BSTRs and such are giving me some severe flashbacks to COM. It reminds me why I really do think .NET is a big step forward.

Another humorous bug…

OK, one more that I found in my archives from the Visual C++ group from 1995. No milk involved this time. Once again, names removed to protect the innocent, except for the one name that’s obviously a joke…

——————– ACTIVE – 01/30/95 – XXXXXXXX ———————–
Visual C++ makes an audible signal when a build completes. When no developer is in the room, this signal doesn’t make a sound. To reproduce:

1) Start a build.
2) Leave the room.
3) Note that the chime does not make a sound.

We should find a way to make the build bell make a sound even if nobody is there to hear it.

This philosophical issue may need program management’s attention before being resolved.
————— ASSIGNED to XXXXXXXX – 01/30/95 – XXXXX —————–
Can we use the telepathy support in Win95 to contact whomever is logged into the machine doing the build? Maybe we should just detect when the developer is leaving the room and prompt for a phone number where s/he can be reached. How about disabling leaving the room during a build?
————— RESOLVED – BY DESIGN – 01/31/95 – XXXXXXXX ————–
——————– ACTIVE – 02/01/95 – XXXXXXX ————————
Actually, we can’t do this either. The problem is that while you’re out of the room your build is neither finished nor unfinished. It stays in a state of flux until you return and collapse the quantum uncertainty by observing it.

Perhaps we could link the build finished event to a cat in a box?
————— ASSIGNED to HEISENBERG – 02/01/95 – XXXXXXX ———–
————— RESOLVED – NOT REPRO – 02/03/95 – HEISENBERG ——-
I cannot repro this. I tried standing just outside my door and it made the beep. Do I have to go further from my office? Would the mailroom do?
——————– ACTIVE – 02/03/95 – XXXXXXXX ———————–
The relative position of the mailroom and your office are relatively uncertain to me, Doctor.

Please try again:

1) start a build
2) leave your office
3) go down the hall
4) wait until you don’t hear the beep
5) return to note that the build is done

I think this is how I first repro’ed the problem, but I can’t remember what I was doing to make it happen.

The idea of disabling leaving the room might be the best possible solution, I think. When a build starts, the IDE should pop up a message that says “There are no more Fritos” or “The kitchen has closed early” or “The bathroom is being cleaned” so the developer will not be tempted to get up and wander around.

With minimal rebuild in place, we should consider diversions that won’t take as long to remedy: “You’re expecting a phone call” or “Someone will stop by to see you soon”.

We need to think of messages that are easy to localize for VC++3.0J.
————— ASSIGNED to XXXXXXXX – 02/13/95 – XXXXXXX —————
To do this we’ll need to avoid messages about the bathrooms and vending machines for external releases. Perhaps some customer research is needed to find out exactly *why* Visual C++ users leave their keyboards.

Some suggestions (including MB_ types)
Get a drink :
(i) You’re out of coffee
(i) You’re out of tea
(i)(i) YYoouuvv”ee hhaadd eennoouugghh

Get something to eat :
(?) You have no food, remember
/! You need to lose weight, fatso. Sit your ass down

Exercise etc :
(?) Did You Know – sunlight causes skin cancer
(i) With a Nordik Trak you can get a workout in front of your monitor. Call for home delivery
/! I didn’t mean that about your weight

See family :
(i) They already know you love them
/! They’ll only want money for something
/! Your in-laws have arrived

Call of nature :
This could be difficult. Consider supplying bed-pan or similar
————— ASSIGNED to XXXXXXXX – 02/16/95 – HEISENBERG ————
I attempted to repro this once more:

I placed my machine in the forest at the edge of the campus.
I started a ‘rebuild all’ and ran out of the forest towards my mailroom.
My build normally takes 3 minutes. After 5 minutes I had not heard anything,
so I returned to my machine. Unfortunately a tree had fallen on it. I had not heard that, either.

Trust Your Instinct Redux

Adam Barr posted a comment on my entry on Joel’s now obviously massively ancient article on interviewing at Microsoft, with some amplified comments in response to Scoble and even more amplified comments in his review of “How Would You Move Mount Fuji?” on Slashdot. (Whew. Way too much hyperlinking going on there.) It seems like there are some deeper issues between Adam and Microsoft that are going on in the background – I’m not quite sure how one jumps from my entry to the idea that I believe that “I work at Microsoft therefore I’m a genius at all things including evaluating talent” – but it is worth noting that I actually agree with many of the points that Adam brings up. Since I was just riffing on a thought I had about Joel’s article, I didn’t really cover everything I think about interviewing. So here are a few more thoughts that I think are worth saying…

To start with the practical side of things, I’ll cop to the fact that I don’t think I’m a great interviewer or all that good a judge of talent. I’m a pretty good programmer and a decent writer (I hope) but I make no claims to be Lamont Cranston. To be even more honest, interviewing people has always kind of terrified me. After a lot of conscious work I’ve gotten to the point where I can do it and feel reasonably secure in doing it, but if SteveB called me up tomorrow and told me he’d written me a Get Out of Jail Free card for interviewing from now until doomsday, I wouldn’t be sad.

Anyway, despite the stories I’ve heard on the web, all of the people who I’ve been on interview loops with at Microsoft have been genuinely interested in the candidates and have tried pretty hard to be being fair, open and honest. But Adam’s right that Trust Your Instinct by itself is hardly sufficient to conduct a decent interview. Too much belief in your own instincts can easily lead to arrogance and condescension. That principle always has to be counterbalanced with the equally important principle of Be Humble or, put an even better way, There But For The Grace…. (This applies not only to interviewing, obviously, but to the rest of work and life. Hubris has destroyed many a Microsoft competitor, and we’ve certainly had our share of near-misses.) The trick is finding the right path between Scylla and Charybdis – too much self-confidence or too little self-confidence can be equally deadly. Do I always get the balance right? Suuuuuuure I do…

One of the things that Adam will probably find most surprising is that I tend to agree with Poundstone’s “fifteen second” evaluation insight. More often than not, the initial impression I get from the very beginning of the interview is pretty much where I end up at the end of the interview, even though I consciously put my first impressions out of my mind. (One is certainly free to draw the conclusion that I do not really succeed at putting them out of my mind, but I would assure you I’ve gotten pretty good at it.) I’ve thought for a long time that the first thirty seconds of the interview are often the “real” interview and then the other fifty nine minutes and thirty seconds are follow-up to catch those times when the first impression is wrong. Which happens, certainly – sometimes people take a little while to get “warmed up” or may be having a bad day of it. But it is amazing how much the non-verbal cues that we’re hardly even aware of can say so much about a person. (I would point to another excellent Malcolm Gladwell piece from the New Yorker on this subject.)

And, finally, I’d completely agree that Microsoft’s style of interview is not a good intelligence test, mainly because that’s not what it’s intended to be. When I interview someone for Microsoft, I don’t really care whether they’re brilliant. I don’t really care if they’re an incredibly hard worker. I don’t really even care if they like computers and/or Microsoft and/or their old bosses. All I care about is, in order: a) can they do the job?, b) can they do the job well?, c) can they do the job well at Microsoft? The goal of the interview, in my eyes, is to figure that out and nothing more. There are really smart people who are nonetheless completely unable to get anything practical done. There are really hardworking people who nonetheless lack the creativity needed to solve difficult problems. Choosing for a single skill or talent or way of working is a really, really, really bad idea. The important question, indeed the only question, is whether the person is a good fit for the job and the company.

OK, one more point. In the case of the intern interview, Adam wondered aloud whether it would really be so bad to “give the kid a chance” and if he didn’t work out then “kick him to the curb and no permanent harm done.” The problem with that is pretty simple if you think about it for a moment. My team gets one intern for the summer (if we’re lucky) and we interview a bunch of college students for that position. It’s not a question of whether the kid is smarter than me or smarter than Bill Gates (in the case of the former, it’s often an even bet), it’s whether he’s going to do a better job than the rest of the kids who are vying for the position, pretty much all of whom are deserving of a break one way or another. I’d love to give ’em all a tryout, but there’s only so much one team can do…

[Hmmmmmm…. “Mr. Stud Interviewer.” I like the ring of that… Darn, now I’ll have to get some new business cards printed up!]

Those darn buggy milk cartons!

For once I get to out-Raymond Raymond and post something from the way-back machine. I’m not sure what it is with Microsoft employees and milk, but here’s another bug report from Excel from 1994 that I saved because it was funny. Aliases removed because a surprising number of them still seem to be around. (The T: indicates the person was a tester, I believe, while D: was for developer and P: was for program manager.)

——————– ACTIVE – 05/12/94 – T:XXXXXX ———————–
: Go to the kitchen
: Grab a Darigold chocolate milk carton
: Read the ingredients list

–! Either Darigold has discovered a chocolate cow, or something’s missing from the ingredients list. It only lists milk, vitamin A, and vitamin D. So where does the chocolate/sugar flavor come from?
——————– ACTIVE – 05/12/94 – T:XXXXXX ———————–
Moo info:

: Grab a Darigold 2% milk carton (NOT chocolate)
: Read the ingredients

–! Says it contains Cocoa, Sugar, Guar gum… Looks like the Chocolate and 2% ingredient lists have been swapped.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXXXXX ————-
looks like an internals problem?
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
UI Problem. I’ll take it.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
They don’t make milk at the Issaquah Darigold. Calling Ranier Ave.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
I can’t repro. Do you have the wrong MILKINTL.DLL?
————— ASSIGNED to D:XXXXX – 05/12/94 – T:XXXXXXXX ————-
By design? I think new US health labeling went in to effect this month.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
Wrong Department. Transferred from Distribution to Production. Left voicemail for “Frank”.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
Reproduces in the Development Kitchen. Need a native build of the Kitchen…
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
This is a feature. IntelliSense labeling knew that you didn’t want to feel guilty about the chocolate in the milk, so it didn’t list it on the box.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXX —————-
Recommend postpone. Reading the ingredients is not a common user scenario.
————— ASSIGNED to EXCEL – 05/12/94 – D:XXXXX ——————
By Design. However, there’s another bug that should be entered:
They got the calories correct on the chocolate milk (190). I still feel guilty.
————— ASSIGNED to EXCEL – 05/12/94 – D:XXXXXXXX —————
I think postpone for after mac release. Also keep the buggy samples fully intact with debug symbols and map file till this one gets reactivated for the next release.
————— ASSIGNED to EXCEL – 05/12/94 – D:XXXXX ——————
Please make sure a copy of the above is stored on \cashcow for future reference.
————— RESOLVED – WON’T FIX – 05/12/94 – P:XXXXX —————
Fixing the package is just a band-aid. We need to come up with a solution that addresses the real problem in 96. My recommendation is chocolate cows.

Please close and assign to DARIGOLD.
————— ASSIGNED to T:XXXXXX – 05/12/94 – T:XXXXXXXX ————
I thought the latest drop of ole2 manager supports insitu ingredient srvr
——————– CLOSED – 05/12/94 – T:XXXXXX ———————–
——————– CLOSED – 05/12/94 – T:XXXXXX ———————–

Maybe we all just drink a little too much milk…

Oh, and one thing I’ve learned is…

…when ordering business cards, order the smallest batch possible. I’ve thrown out tons of perfectly serviceable business cards in my career so far because the cards failed to keep pace with whatever I happened to be doing at the moment. So this time when I ordered, I ordered as few as I could. They’ll still probably mostly get thrown out, but at least that saved some paper.