Author Archives: paulvick

The Story of the Bill Gates Quote

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:

Book Cover

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?”

Oh, s**t.

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…

My (Terrifying) Meeting with Bill Gates

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…

How on earth do normal people learn C++?

I’m asking this seriously. How?

One dirty little secret around Microsoft is how little “real” C++ code is written around here. I think a lot of it has to do with the fact that when C++ was first coming into it’s own there were a number of high profile projects that enthusiastically adopted C++ but ran into a lot of problems. Some of those problems had to do with the immaturity of the tools (produced by Microsoft), some of them had to do with a lack of experience with C++ (since, of course, it was relatively new at the time), and some of them had to do with the “when you have a hammer…” effect. The end result is that although a lot of projects I’ve worked on have had “.cpp” file extensions on their source code, in many cases you could rename the extension to “.c” and it would compile with very few changes.

Lately, though, I’ve been having to do a lot more modern-ish C++ programming, and while I have an amazed respect for the sheer amount of power available to the C++ programmer nowadays, I am also baffled how anyone can actually understand what the hell they are doing half the time. Don’t get me wrong, I feel like I get by pretty well in C++, but then I spent a decade designing a OOP language, building a compiler for it, and debugging the whole thing. There are lots of times when I’ve been able to survive in C++ only because I can fall back on a mental type system model that was built up through a lot of blood, sweat, and tears. I wonder how people who haven’t had that particular experience actually grok a lot (sometimes, any) of what C++ does.

I’m guessing people just throw a lot of code at the wall until something sticks, or maybe just copy and paste from Stack Overflow. I don’t know. But, seriously, sometimes I think you should have a license before you should be allowed to attempt C++.

Either that, or I’m just being dense. Sadly, that’s always a possibility.

On TypeScript and writing maintainable JavaScript programs…

As I’ve mentioned, I’ve been using TypeScript quite heavily for some internal prototyping that I’ve been doing. As such, I’m starting to form various opinions about it, and overall I really like it (which makes sense, given my background). One thing I’ve been thinking about lately, though, is the quote from Anders Hejlsberg that ricocheted around a while back and which obviously prefigured the TypeScript work:

No, you can write large programs in JavaScript. You just can’t maintain them.

Clearly, TypeScript is intended as an answer to this problem, and I’ve found that it definitely helps me keep my program more in line and not have it wander off in some strange direction I didn’t intend. But it also doesn’t “solve” the problem of maintaining large JavaScript programs any more than the invention of the hammer “solved” the problem of building large buildings. If I don’t follow my usual rules of thumb when programming (think about what I’m doing, keep my code clean, review and rewrite, etc.), my TypeScript code becomes spaghetti just as quickly as my JavaScript code ever did.

Ultimately, the problem is that a tool is only ever as good as the person wielding it. In that sense, I disagree with Anders’s sentiment above–I think it’s entirely possible to write very large codebases in JavaScript that are maintainable, it just requires a somewhat higher degree of discipline and effort than in a language like TypeScript. And the delta of effort between the two languages isn’t as high as those of us who work in the language space would often like to believe. If TypeScript catches on (and I hope it does), there’s probably going to be vastly more bad code written in TypeScript than good code. The difference from JavaScript is that it’ll just have more type annotations…

 

Undoing some of the damage…

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!)

The Use/Build Fallacy

Working in the language space, especially in language design, you frequently encounter people who fall victim to what I call the “Use/Build Fallacy.” It goes something like this:

Because I know how to use something, I know how to build it as well.

This fallacy is best illustrated by a story I heard from a friend who’s a teacher (another profession that frequently has to deal with this). She was teaching middle-school when teacher conferences rolled around. Talking to the father of one of her students, she explained to him that his daughter was having a lot of trouble in English class and that, based on her observations of how hard the daughter was working, she was pretty sure that the daughter had some sort of language learning disability. She therefore strongly recommended that he take his daughter to an expert to get tested, and that she be tutored by someone trained to deal with the specific kind of learning disability. The father was nonplussed, mainly because he didn’t like the idea that all this would cost him money. “Can’t you just help her more in class?” he asked. My friend explained that she was helping her all she could, but she wasn’t an expert in diagnosing learning disabilities and his daughter really needed to see someone who had the appropriate training.

After a bit of back-and-forth, the father finally got exasperated and said, “Fine, I’ll just tutor her myself! I mean, how hard could it be? I went to school!” My friend then shot back, “Look, you’re a general contractor, right? What would you think if I came to you and said, ‘I don’t need you to build my house—I’ve lived in a house before, so how hard could it be to build one myself?” This, finally, stumped him. I’m not sure whether he actually got his daughter the help she needed, but the story stuck with me because my friend’s response is the perfect distillation of the Use/Build Fallacy.

Note that I’m not saying that just because you’re not an expert on something you can’t have an opinion. I may not know how to build a house, but that doesn’t mean I have nothing to say to the contractors if I decide to do some renovations on my house. Not falling prey to the fallacy, though, means that I always keep a healthy respect for the expert in a field—as long as they truly seem to know what they’re talking about. (I hear this from friends who are architects all the time—they get hired by someone to build or renovate a house for them, and then their client spends all their time endlessly arguing with everything they do. Why bother to hire an expert if you think you already know how to do it yourself?)

I try to remember this myself every time I encounter some aspect of some programming language that I don’t like. Right now, I’m neck-deep in C++ code and it’s tempting to spend all my time kvetching about how how horrible a job Bjarne has done over the years. And then I try to remember—even as someone who’s actually built a language—that this stuff is hard. A language of any complexity has a huge number of moving parts, all of which interact with each other in an unpredictable manner. Historical choices can come back to bite you in all sorts of unexpected ways. Oftentimes all you have are a bunch of imperfect choices, and you have to simply pick the least bad of them all. And then you get to sit there and listen to everyone on the sidelines complain about how horrible a job you’ve done and how they could do it so much better than you because, hey, they’ve used a programming language before.

So I try to temper my complaints with a little humility, and remember how much different building is from using.

I used to be a blogger like you…

…until, well, you know. I realize it’s been quiet around here. Sorry about that.

At any rate, after about 18 months in the SQL engine, I’ve moved yet again. I think I gave a good run at it, but in the end I decided that it wasn’t working and that it was time to do something different. Ironically, I think the biggest reason SQL ended up not working out for me was something that the team decided to do right, namely going all-in on the cloud (i.e. SQL Azure). The problem was that when I originally joined the team, they weren’t quite there yet. The SQL organization was just starting to look beyond SQL Server 2012, all options were on the table, and one of those options was that the team might be willing to take a harder look at the language processing parts of the engine and their future. Then, about a month or so after I moved over the team coalesced around the decision to go all-in on the cloud and make SQL Azure the most amazing cloud data platform possible. And while I think that was totally the right call, it did mean that priorities got shifted and there just wasn’t going to be the kind of headroom to do the kinds of things that I was interested in doing. So instead I got to spend about a year and a half learning a lot of interesting things about the cloud and running a service in the cloud. But in the end, that’s not where my heart lay and so I decided to try something new.

Well, sort of new.

You see, I was chatting with some of my old compatriots back in the Developer Division (including some people I’d spent a lot of time working with on VB) and found that they were doing all kinds of interesting things with this weird little language that apparently a lot of people think sucks. It turns out that somewhere along the line this language that a lot of people think sucks somehow became this totally important language that lots of people were very, very interested in. And they were looking for some more people to work on it. And would I be interested? After thinking about it a bit, I decided that it could possibly be a lot of fun to work on a language that most people deride as a horrible language but which somehow is the crucial underpinning of lots of important things. (Reminded me of some stuff I worked on a few jobs back.) So I decided, why the heck not?

So, I’m now a newly-minted member of the Javascript team. Part of my job is just contributing in any way that’s useful to all the cool stuff that we’re already doing (yay Windows!). Part of my job is to do some looking forward as to where we might go with Javascript. After all, there’s lots of interesting things being done with Javascript beyond just running web pages.

So now you know.

You should also follow me on Twitter here.