About a year and a half after doing something I swore I’d never, ever do, I have to admit… it didn’t stick. While working in Windows during the Windows 10 initial cycle was fascinating and fun, it turns out that I just miss working in programming languages too much to become a long-term member of the Windows team. I had a great time working with some great people (and a few of the things I worked on are just about going to go public…), but in the end, I’ve been lured back to the PL world.
Interestingly, I’ve decided to return to the team I left seven-odd years ago just as they were beginning to start this crazy re-write of the VB and C# compilers into managed code. Now that Roslyn has shipped, I felt it was finally safe to return… So I’ve accepted a position back on the Visual Languages team. I don’t plan on doing anything specific with Visual Basic — that language is in very good hands at the moment — but will be working on some ideas about how we might leverage Roslyn to do some interesting stuff. More information to come as it becomes available!
Although, as I said before, I can’t talk specifically about what I’m working on in Windows for the time being, there are some general things I can say. The main thing I’m doing right now is some investigations around the diagnostic API surface of Windows. By “diagnostic,” I mean any information that Windows may possess regarding the internal state of the system at any particular moment that might be useful for understanding what’s going on. This is a pretty wide-ranging definition, covering everything from the current state of a thread up to the current state of the operating system itself.
The thing is, Windows contains an enormous amount of information about the state of things at any particular moment, but getting to that information can often be difficult or impossible. For example, a lot of components in Windows expose Event Tracing for Windows (ETW) data which can be used to look at what’s going on inside that component. The problem is that you have to know: a) which of the 100s of components that expose ETW events you should be looking at, b) which events that component surfaces you should be looking at, and c) what they mean. And usually there’s little or no documentation for any of it. In other cases, there isn’t even ETW events available–the data is just locked up in the internals of the system (unless Mark Russinovich has found it, of course).
The question I’m looking at is whether there are things that we could do to make Windows diagnostic information more available to developers (who could then use it to better understand their applications, or to build better tools for developers). I have no answers as of yet and, of course, nothing may come of this, but there you are. If you happen to be a Windows developer and are interested seeing some aspect of Windows diagnostics become more available to you, drop me a line in the contact form, I’d love to hear from you!
It occurred to me the other day that my old VBParser samples for VB 7.1 and VB 8.0 had gotten lost in the ether somewhere along the line and were no longer on my website anywhere. So I dug up the sources and added them to my GitHub profile. I kind of seriously doubt that they’re a lot of use anymore, given that they are at least, what, three versions out of date now? But who knows?
OK, so I’ve worked at Microsoft… a long time. This summer, it’s going to be twenty two years since I first started full time, and twenty three years since I was an intern. During that time, I’ve worked in a lot of different places in the company. The Developer Division. Office. Developer Division again. A little division that doesn’t exist anymore, the Connected Systems Division. SQL. Developer Division again. And in all of that time, I had one cardinal rule: I was never, ever, ever going to work in Windows. No matter what happened, no matter how desperate I was, I was just never going to take a job anywhere in the Windows organization. No way, no how.
It’s not that I had anything against Windows or the Windows group, it’s just that for most of my tenure here so far, the Windows group has seemed… a little nuts. Not nuts in terms of what they’ve produced (although the whole Longhorn thing, ug), but in terms of how they seemed to work. From the outside, it looked like Windows was always on one kind of death march or another, from Windows 95 all the way through Windows Vista. And as much as I might like the OS, I just never thought that I was hardcore or badass enough to be able to withstand that kind of pressure.
There was also the fact that most of my career has centered around developers in one way or another, and for most of my time at Microsoft, Windows has been content to simply outsource the majority of the developer relationship to the Developer Division. This isn’t shocking or anything–hey, “Developer” is right there in the name!–but it meant that if I wanted to be working on developer-related stuff, there was only one place to be.
I decided to do this for two reasons. The first one is that since Windows Vista the Windows team seems to have adopted a much more sane attitude towards the whole work/life balance, something I got to see up close while working on a component that ships in Windows. They still work hard, don’t get me wrong, just that they no longer employ burly fellows to walk along the hall cracking whips every half hour.
The other reason is that since the Windows 8 cycle, the Windows team has a much more serious attitude towards supporting developers. They’ve even got a whole organization dedicated to it that works closely with the Developer Division and everything! And so when some acquaintances started chatting with me about some of the ideas the developer team in Windows had for future versions of Windows, I got interested. And then did an interview. And then accepted. So now here I am! Most of what I’m going to do isn’t public for the time being, so not a lot to say about that at the moment, but suffice it to say, I think it’s going to be interesting!
One of the great things to do in my neighborhood is to head over to Central Cinema, a small movie theater that serves food and drinks, and which has decidedly eclectic tastes. The best thing they do, speaking as a parent, is their “Cartoon Happy Hour” every Thursday where they show a wide range of cartoons for kids (and parents) to enjoy. It’s been a great opportunity to introduce my kids to cartoons that I watched as a kid (Hong Kong Phooey! Tom and Jerry! Looney Toons!) that they might not otherwise get to see.
Recently they’ve shown several episodes of Speed Racer, a cartoon that my mom would never let me watch because it was “too violent.” (Compared to modern cartoons, it’s positively milquetoast.) So it was fun to finally watch it with the kid, but when the theme song came on it triggered a nostalgia of an entirely different sort.
It reminded me of that day, long ago, when I actually got to pick the codename for a product. Looking back now, I’m not exactly sure why I was so keen to pick a codename–it’s not like it’s prestigious or anything–but I definitely was. I wanted to set the name for a whole product cycle, really wanted to. And when the cycle for Access ’97 came along, I got my chance, for two reasons. The first was that most of the team had split off to do a re-write of Access that was supposed to ship after Access ’95 but then got pushed back to after Access ’97 (and then cancelled), so pretty much all of the senior people were no longer on my team. And because Access ’97 was supposed to be a placeholder until the rewrite was finished, it was decided that the bulk of the work on the release was going to be solving the major performance issues we incurred moving from 16-bit Windows 3.1 to 32-bit Windows 95/NT.
Since I was heading up the performance work, I saw my chance and pushed to pick the codename. Of course, picking a codename wasn’t that easy–what would be cool name that would go with the idea of speed? That’s when Speed Racer flashed in my mind, and so the codename for the release became “Mach5,” named after Speed Racer’s car. In the pre-YouTube days, I even got a VHS tape of a Speed Racer episode and went over to Microsoft Studios to get them to convert the theme song to an AVI so I could send it around to the team. (Boy, was I a bit of a geek.) Mission accomplished.
Now, of course, you could never pick a codename like that. In our litigious society, people sue over codenames. I actually saw this in action–there was an old internal project at Microsoft that borrowed its name from a well-known company that makes little plastic bricks. Even though the tool was completely internal and never used or discussed publicly, the codename somehow ended up on some stray public document. The company in question was alerted to the use of the name, the lawyers got involved (so I heard), and in short order the tool was renamed to an innocuous acronym.
In the useless memories department, xkcd’s cartoon today took me back:
In my junior year of college, I took the standard programming languages course that goes over fun stuff like how programming languages are put together. The main project for the class, of course, is to build a compiler for a small language. The twist was, that the professor for this class happened to be one of the designers of the Haskell language, so you can guess what programming language the compilers had to be written in.
The thing is, this class took place probably in the fall of 1990 or the spring of 1991. According to Wikipedia, Haskell debuted in 1990, so first and foremost the tools we were working with were… uh, primitive at best. I think the Haskell interpreter was written in Common LISP, and basically you took your program, invoked the interpreter on it, went and got yourself a nice cup of tea (so to speak), and then came back to an answer (if you were lucky), an undecipherable error message (if you were only kind of unlucky), or just nothing (most of the time). Definitely honed the skill of “psychic debugging.”
Anyway, with a brand-new language (that, of course, had no manuals or books written about it yet) and an alpha-level (at best) compiler, as I remember it at least half the class never even managed to get something working. I somehow managed to grok enough of Haskell to be able to write a functioning compiler that took our toy language in and produced correct output. I was one of the lucky ones. But here’s the thing…
It was, without a doubt, one of the most beautiful programs that I’ve ever written. Just a real work of art, with the data flowing through the code in one of the most natural ways I’ve ever seen. Just awesome. It’s the one piece of code that I look back on and wish that I still had a copy of.
So I’ve always had a soft spot in my heart for Haskell. Even if nobody else could actually understand what it was doing or why.
Recently I told the story of my one product review with Bill Gates, and I said that there was one other terrifying encounter I had with him (well, really, his world) but it would have to wait for another day. As luck had it, I was talking with someone a couple of nights ago who works in Bill’s extended universe and ended up relating my second story, so I thought I’d go ahead and share it here too.
Those with long memories may know that I wrote a book on Visual Basic that came out around the time of Visual Studio 2003. Here’s a picture of it, from Amazon:
If you look up there at the top of the book cover, you’ll see a teeny quote that reads:
Visual Basic is a cornerstone of Microsoft’s development tools–and this book is a key language reference for Visual Basic. — Bill Gates, Chairman, Microsoft Corporation
How exciting! Bill f**king Gates read my book! Well, not really. Here’s what happened…
It all started when my publisher said that they were going to be meeting with Steve Ballmer to discuss the .NET book series that my book was a part of. They said that they were going to ask if maybe Steve would be willing to write a forward for my book since BASIC has such a long and storied history at Microsoft. I said that sounded great and then it hit me that I was friends with Bill Gate’s technical assistant at the time, and so I said that, hey, maybe I could see about getting a forward from Bill himself (since of course, BASIC was his first product!). They thought that was a great idea, of course, so off I went.
My friend directed me to Bill’s writer (the guy who did speeches, etc.) and I had a nice chat with him through email. He said there was basically no way that Bill would do a forward since, as you can imagine, he was getting millions of requests to write forwards and they just had a blanket policy of saying “no.” In talking a little, he did say that he thought it would be OK to do a quote for the cover, assuming that everyone understood that: a) this was a one time thing, and b) not to go around talking about how Bill gave me a quote for my book, since they didn’t want to open the floodgates or anything. He thought it was a small enough thing that I could just come up with the quote, he’d wordsmith it and approve it, and we’d be done–no need to get Bill involved in something so small. Great! I told my publisher and they were ecstatic.
Then one morning I come into work and I’ve got an email in my inbox from someone in my VP’s office saying, “I need to talk to you about a quote your publisher is getting from Bill? Do you know anything about this?”
You see, if there’s one thing I’ve learned about powerful people, it’s that they tend to have an “external immune system” made up of people who’s job it is to filter out the avalanche of requests, demands, pleadings, and just plain crazies who want to get some part of them. It’s just a fact of life. And, furthermore, if you’re dealing with a powerful person you do not want to trip this immune response because it can get pretty tense pretty quickly, especially when you happen to be working for the company that they run. Which it became clear pretty quickly was exactly what I had done.
What had happened was that someone high up at my publisher had met with Bill for some reason or another, and in conversation had thanked him for providing the quote for my book. At which point, Bill apparently said, “What quote?” And BOOM! the immune response started gearing up, trying to figure out exactly where this “quote” had come from and who exactly it was who was claiming to speak for one of the richest men on the planet. Within hours, I was in conversation with senior people at my publisher, with Bill’s personal assistant, with my VP’s personal assistant, with my VP himself, and with Bill’s writer (who, understandably, was not pleased that I had managed to screw up this favor he did me). In the end, I profusely apologized, the quote was vetted a bit more, the immune response quieted down, and the book got published. But it was very tense there for a moment. I really didn’t want to be known to upper management only as “the guy who tricked Bill Gates into giving him a quote for his stupid book.”
Suffice it to say, time has gone on. I moved on from VB, Bill’s moved on to other pursuits (as has my old VP), and the book, while it did OK, was never updated past 2003. But just reading the old emails, which I did in preparation for writing this, got my heart going again just a bit. Not something I think I’d ever want to repeat…
This being Halloween and all, I thought I would relate one of the most frightening experiences I’ve had in my two decades working at Microsoft. I was reminded of it this weekend when we had a small reunion for everyone who’s worked on Access over it’s 25-or-so year history–it was a bit of old home week, seeing people who in some cases I haven’t seen in well over a decade and a half.
Anyway, it reminded me of an old practice at Microsoft called the “BillG review,” which was a (I think) twice-yearly meeting every major product team had with Bill Gates. They’d go over their progress since the last meeting, talk about their future plans, and give him the chance to ask questions and give direction. As one can imagine, this was a really huge deal (especially back in the days when Microsoft was still a 12,000 person company). A bad BillG review could be extremely traumatic, especially since Bill was not particularly known for his warm-and-fuzziness, nor did he suffer fools gladly. It could also radically alter product plans, depending on whether he agreed with what you were doing or not.
For most of my time in Access, I was too junior to actually attend these reviews, much less give any part of the presentation. I’d mostly just hear about it in the form of a flurry of design changes after each one. But by the time we’d gotten to working on Access ’97, a large majority of the senior folks had split off from the team to work on an ill-fated rewrite of Access. The main focus of Access ’97 was doing something about all the performance we’d lost moving to 32-bit (i.e. Windows 95) and integrating COM and VBA for the first time, and I had self-elected myself to be in charge of the development side of that effort. So when it came time to do the BillG review, I was tapped to give part of the presentation on the performance work. I was also there to throw to the lions in the eventuality that Bill started drilling in on some highly technical question, as he was famous for doing (c.f. Joel’s discussion of his first BillG review).
So the day of the review rolls around and I show up at Bill’s executive conference room with the rest of the team and various Access leaders. Of course, Bill’s running late, so Tod Nielsen (who was Access business unit manager at the time, I believe) decides to entertain us with colorful stories of BillG reviews past. And he decides to tell us the story of the final Omega BillG review.
Now, Omega was the desktop database project that preceded Access. They worked on it for about a year and a half (I think) before it got cancelled, all the code was thrown out, and they restarted on a new project that became Access. I wasn’t around for Omega, but I had heard lots of horror stories about it getting cancelled from people who’d been on that team. As you can imagine, then, the final BillG review for Omega was probably not a particularly happy event.
As I remember Tod telling it, he said that they were going through a list of what wasn’t going well with Omega when, all of a sudden, Bill loses it and starts swearing. “Get f–king recruiting in here, I want f–king recruiting in here right now!” Everyone’s a bit puzzled (and worried), and so they say, “OK, Bill, why do you want recruiting?” He replies, “Because I want to find out what f–king colleges we recruited you guys from and tell them not to f–king recruit there any more because they clearly produce f–king idiots!” Ouch. At that point, the team knew the review was over, so I they basically said, “All right, Bill, we’ll let you calm down and talk to you later,” and left. Tod thought the whole thing was hilarious… now. (It’s also possible he embellished the story a bit, I can’t testify to the veracity of his tale…)
Of course, as the person who was about to present about the primary feature of Access 97 to Bill f–king Gates, I was absolutely terrified. Great, I thought, I’m totally screwed. I’m going to die. Thankfully, Bill showed up, we did the review, and aside from one tense moment, everything went extremely smoothly. Then I got to sit and listen while Bill and the VPs sat around for a little while and discussed when they were going to merge our division in with Office, like they were moving pieces around on a chess board. Fascinating.
Not coincidentally, my other “scariest story” from my time at Microsoft also involves Bill Gates, but that’s a story for another time…
OK, well, this is a bit embarrassing, but here goes: you know how I threw away the accumulated blogging of nearly seven years (a.k.a. Hitting the Big Red Switch) in favor of a clean slate?
I realized maybe that I went… a little bit overboard.
Having just now completed what I can only describe as one of the more trying periods of my life (getting separated, getting divorced, selling a house, along with some questionable career decisions, none of them experiences I can recommend to anyone), I can look back and say with some conviction that my decision to drop my blog history was motivated in no small part by a desire to wipe my entire slate clean. Unfortunately, I think I ended up throwing out the baby with the bathwater since there were some genuinely useful stuff back in there. (And a lot of stuff that I’m sure no one will ever care about again, if they ever did.)
At any rate, I sucked it up, pulled out the data backup and ported all the blog posts over to WordPress. So my entire blog history has been restored. Yay! There are still some image links I’m working to restore, but by and large it’s all there. So enjoy!
(I realize it’s been quiet around here. Not much I can say about the stuff I’ve been working on (sooner rather than later, I hope), although you should really check out some of the cool stuff that some of my coworkers have been doing with TypeScript. It’s awesome!)
I ran across this great blog entry today called “What’s The Most Difficult CEO Skill? Managing Your Own Psychology”. I don’t expect to ever, ever, ever be a CEO, but I think a lot of the lessons that Ben Horowitz talks about apply to just about any leadership position you might ever find yourself in, from team lead to Little League Coach. Thing like needing to learn to handle stress, needing to take the responsibility seriously but not too seriously, needing to cope with loneliness, etc. But the thing that caught my eye was the end of the entry:
Whenever I meet a successful CEO, I ask them how they did it. Mediocre CEOs point to their brilliant strategic moves or their intuitive business sense or a variety of other self-congratulatory explanations. The great CEOs tend to be remarkably consistent in their answers. They all say: “I didn’t quit.”
In my experience, this one phrase—“I didn’t quit.”—is the dividing line between success and failure. A few of the successes that I’ve had in my life (such as they are) can be attributed to dumb luck or raw talent. But most, and certainly the most satisfying ones, were primarily attributable to the fact that I didn’t give up even though I often might have wanted to.
The hard part is that it’s often impossible to know whether you’re on the right path or not. Sure things may turn out to be dead ends. Things that people say cannot be done may turn out to be golden opportunities. The best thing you can do is be clear on what’s important to you, follow your gut, and… don’t quit.