SQL Server Geek (5 Years) and VB-Coder of Opportunity (3 Years) Working for EDS as unimatrix 3 of 5 in the ADSC SQL Server DBA Team. Security and Integrity counts. If you can't do it, we will do it for you.
Check me out on the web at EDS Home: Business Process Outsourcing, IT Outsourcing and Application Services | eds.com or at my blog.
I'd just like to say that while it's more or less true that "Source code IS the ultimate documentation," there are some downsides to this approach. For starters, I don't have time to go through every piece of source when looking how to use a library.
As part of a "Code Factory" organisation, what I need is complete and reliable documentation on what to use in which situations, and how to use some of the more obtuse options in otherwise well documented libraries to solve real world problems.
Knowing how to make complete use of all of the functionality available in a given tool is more important to me than knowing how the tools were written. Microsoft pays a large number of people who know what they're doing to handle bug-fixes and tuning. I'm
pretty certain that (as a casual client-side coder) any attempt I made to fix or tune the CLR would create more problems than it solved. And ultimately, in a large corporate applications factory, you're only as good as the last crisis you caused.