I found this on digg.com and liked the short, honest style. Bottom line: anyone can write a book; it takes real work to write a good book.

I wanted to figure out how to emit a new CLR type at run-time using Reflection.Emit and Google revealed the following article: Generating Code at Run Time With Reflection.Emit in DDJ.As usual, I skip most of the initial prose to the first code sample (I don’t need some author’s fancy intro — I just want the code!). Then, I’m reading along and I find some phrases I enjoy, e.g.

“If you plan on generating lots of calls to Console.WriteLine(), you should be aware that the ILGenerator class exposes a method for just that purpose: ILGenerator.EmitWriteLine() generates the exact same code as our example. (Could this be the first assembler ever devised that includes explicit support for creating “Hello, World” sample programs?)”

and

“When creating a dynamic assembly with Reflection.Emit, you must declare, ahead of time, what you plan on doing with it. Do you want to run it or save it? Or both? (Of course, if your answer is ‘neither,’ then you should probably should have stopped reading this article long ago.)”

By the end of the piece, I’ve enjoyed the story and it told me exactly what I wanted and then some, pointing out some pitfalls I would’ve missed, being entertaining along the way. It’s rare that I enjoy an article so much and I’m thinking I should send the author an email, congratulating him/her on his/her tight, fun prose.

And then I get to the author bios:

″Chris Sells is a blah blah blah.”

″Shawn Van Ness is a blah blah blah.”

Of course, now I remember Shawn writing this piece and me helping him with the polish. At this point, I feel a bit like the Joey Tribbiani of Windows technical writing…

I work on the same team as Don and Chris to which this article refers. There’s few actual facts in this piece and some of those are wrong (love Chris like a brother, but he wasn’t on the WCF team : ), but it’s interesting that my little group is making its way into the news.

BTW, as a matter of context, I’m not a big codegen fan (in spite of my previous dealings : ) and it would be a mistake to think of “modeling” as “fancy codegen,” in spite of what this article implies.

Shawn Wildermuth, author of the Silverlight appendix in Programming WPF, has put together a comprehensive 3-day shortcourse on Silverlight and is taking it on road to Atlanta, Boston, Chicago, San Fran, Dallas, Seattle and DC. Sign up today!

Welcome to Microsoft, Scott Hanselman!

Buy your copy today! : )

P.S. I read the QC1 (Quality Check 1), all 859 pages of it, in two solid days this weekend. I found a bunch of nits, all of which will be fixed before you see it in August. Wahoo!

I knew something was up when the Home Server team climbed onto a bus Friday afternoon outside of building 42. They were obviously celebrating something. This morning, I found out what it was -- Windows Home Service RTM shipped! Congrats, guys! I can't wait for the RTM bits to be available internally so I can install it. I've got a machine all picked out. : )

A friend of mine is going for an Microsoft interview next week and he IM’d me asking for any “unpublished tips” for interviewing at MS (apparently he’d already read all my published tips). Frankly, I don’t know if these are published or unpublished, but these were the ones that I thought were most important:

• Your interviewer cares most about 1) how you think and 2) what you feel, so be vocal about both. You might not get the job, but if you do, it’ll be a better fit than if you’d have kept your mouth shut.
  
• Don’t be afraid to ask clarifying questions. This is more detail on the “let ’em know what you’re thinking” point above. If you don’t understand the problem fully, don’t jump in to solve it before you do. Or, if they ask you something potentially scope-less, e.g. “Tell me about yourself,” feel free to ask for a scope, e.g. “I’m 38 years old and a lot of stuff has happened. : )  Would you like to narrow that question down a bit for me?” (or something less smart-ass-like if you’re not able to carry off smart-ass-ness with a smile).
  
• Let the interviewer know how you feel about the job. At Microsoft, you’ll have quite a bit of latitude in how you do your job, so they want to know that you care about the same things they care about so they can set you loose and know good things are going to happen.
  
  Think about the job before you show up so that you have an agenda. It often helps if you can list a bunch of reasons Microsoft is currently screwing the pooch in your area. I can’t tell you how many times I’ve heard about someone railing against Microsoft because of something we’re not doing right and that person gets a job offer to go fix the thing they were complaining about (“Put up or shut up” is a big part of the Microsoft culture).
  
  One thing to watch out for: if you do have an agenda, make sure it’s something in your proposed job scope. If you’re hiring as a mid-level Program Manager, you’re not likely to have much impact on how MS builds software all up, but you can definitely work to fix how your group-to-be is doing it.
  
• Answer questions from your own experiences. If someone asks, “How do you deal with conflict,” don’t give them the stock, pat answer. Instead, reach into your experiences and pull out a specific example. This will give your answer more credibility. This technique runs the risk of the interviewer not liking how you handled the issue, but again, do you really want a job where you’re not a good fit, but nobody knows ’til you’ve sold your house and put the kids into a new school?
  
• You have to like us, too. When Microsoft is interviewing you, remember that you’re interviewing them, too. Make sure you’re going to like the work you’ll be asked to do and the people you’ll be asked to work with. It’s not good for *anybody* if you show up for work and don’t fit in because you didn’t ask questions. Plus, when the interviewer says “Do you have questions for me?” you better have some, or you’re not going to come across as someone that actually cares about the position.
  
• Don’t talk about money during the interview. There’ll be a short window between the time they offer you the job and the time when you accept it that you’ll be able to discuss compensation frankly. If you do it at the interview, you’ll look like you’re after the job for the money and not because you have a burning desire to fix something Microsoft is currently doing wrong or not doing at all.

Bottom line: your interviewer wants make sure you’re a fit for Microsoft, a fit for their team, that you’re smart and that you’ve got passion to do the work that they want you to do.

Good luck!