ricom

Well, having gone through this not too long ago I thought it might be useful for people here to know kind of how the show is made.

A couple months before the taping, shortly after agreeing to do the show, the guest to be gets some emails requesting information.  It's not exactly a resume request but basically it's people they should talk to, background information, an outline of interesting events that happened to you, stuff like that.

During the next couple of months, they meet with people you suggested to get some background, and they have a couple of meetings with you to talk about those same things.  That's a good time to collect pictures or other keepsakes that might be interesting to highlight on the show.

In the week before the taping you have a final walkthrough where they show you the studio, where you will arrive, who the people working with you will be and so forth.  All the logistics.

Then there's the taping.  It's about 90 minutes of taped show.  The host (Keith) never tells you exactly what he intends to ask but you sort of know what the questions are likely to be because you gave them all sorts of seed information.  You don't know which people they talked to ended up giving the best interviews.  Basically he could ask anything about your life that he thinks is interesting.  The only thing you know for sure is he's gonna go mostly chronologically.

After the interview there's Q&A with the audience, and then you're pretty much done.

The show folks edit the 90 minutes down to an hour, so they save your best stuff and probably the best question or two.  The rest ends up on the cutting room floor.  Which is probably good because probably invariably the guest ends up thinking one of his/her answers was lame and it's just as well that the world doesn't have to suffer through it.

After the show airs, they show it formally here in house a couple of times and you do live Q&A.

A few months after that, it's someone else's turn and you're officially a Behind The Code has-been like me

So, the interview itself is pretty candid, but the environment is very professional.  They had a makeup person for me and so forth and I'm sure my skin has never looked so perfect since and may never again.  A very professional looking person used a light meter in my presence, and there were two high quality cameras running at all times.

In contrast, Charles has interviewed me a couple of times and it's much more informal, you get whatever happened that day pretty much however it came out, editing is very light, and we do the best we can in the environment that we have.  Channel 9 is great for that real life feeling.  Makeup and lighting persons are nowhere to be seen -- unless Charles uses one

So, it's not like there's a script for Behind the Code but there is considerable planning.

Does that help?

You might like this one from about 2 years ago.

Or you might like this one from last year.

And of course there's some good materials on my blog and this bibliography.

I don't have anything much more recent than that because Charles doesn't love me anymore

While it's true that I wrote the initial version of "Data Tips" (I'm sure that's what we called it even though the show says Value Tips)  it's also true that the current version probably has nearly zero bytes of my code left in it. 

If anything is left its in the part that evaluates C++ expressions, I did work in that area while I was the debugger lead and a lot of it is still in use as far as I can tell.

I keep a good general bibliography of performance related stuff here.

And the one you want in particular is here.

   -Rico

You don't even need a .h file in .NET

You could in fact have the same set of API's in a variety of library formats.  The tragedy is that although it's possible I think I can say definitively for Microsoft libraries that we've never actually done it before.

There's always bizzare gotchas.

The day that video was recorded I had actually just been trying to get some unmanaged DLLs to talk to one another and I'd ended up having to write code like this

extern "C" _declspec(dllexport) void WINAPI Foo(...)

And I thought to myself... nobody should have to type that crap.

And it gets worse.  If you're doing dynamic binding to DLL's you don't even get compile time warnings if you get it wrong.  Ugh.  You should read some of the history on this stuff on Raymond Chen's Blog

http://blogs.msdn.com/oldnewthing/archive/2004/01/15/58973.aspx

Even when we got it right it wasn't exactly easy.  Back in the good old days when I worked on C/C++ 7.0 and then Visual C++ 1.0 and we were delivering a perfectly nice MFC 1.0 and 2.0 but those guys were like Baskin Robbins 31 flavors.  Do you want unicode or not?  ODBC? COM?  DLL or static linking? 

I'll have static linked unicode hold the mayo.

There was a lot of secret sauce behind the scenes to make that work.  And if it didn't work quite right there was sauce all over the place.

Other great libraries, I mean seriously really useful stuff, like say the XML DOM library or the OLEDB libraries.  They work great but try explaining to someone how to initialize it all from scratch.  Ooowwwieeee!!!  Thank goodness for samples. 

I suspect that the situtaion is not all that different in the Linux world.  Back when I was linking for good old BSD 4.1 there was already library hell... bigger more robust libraries just magnify the problem.

So, if you remove calling convention issues, and make it so that libraries have self-describing dynamic linkage you go a long way to eliminate friction.  That's a good thing.  But people then do think less about what library they are going to use.  Usually that's good too... who wants to live in a world where simple stuff is hard? 

Cheers and thanks for watching,

  -Rico