Last week's .NET Rocks show with Jeff Richter was a great one. I always find it interesting to hear about the types of things that went (and are still going) into the design/implementation of the CLR. During the show, Jeff mentioned a couple of tips for helping the garbage collector be more efficient.

Keep object lifetimes as short as possible. I think this is essentially the same advice that's usually given for dealing with unmanaged resources (file streams, database connections, etc) -- get it late, release it early. It also tells me that I need to do some more reading up on WHY this is the case in the GC. My assumption is that it has to do with objects getting promoted through various levels of the GC and how often it runs through to free up memory. Definitely need to get a good book on the CLR guts. Suggestions?

Keep the call stack as short as possible. Again, I'm not sure why this is and plan to read up on it in more detail. But it does seem at odds with the common design/implementation goals of loose coupling and short methods. Usually, you want lots of small, cohesive objects that work together to form a larger component. Within those objects, you want relatively short methods that can use one another to perform an operation (do one thing, do it well, and do only that). The side effect of that approach is that the call stack gets fairly deep in short order. It may be that 95% of me experience in .NET  has been in the Winforms world -- wherein applications typically (and as was mentioned on the show) are going to have deeper call stacks than ASP.NET applications.

Anyway, interesting stuff... now off to find some good under-the-hood GC resources.

The more of his "Business of Software" articles I read, the clearer it is that Eric Sink just "gets it". I've read the BoS series on MSDN from the start, as well as his various weblog posts, and it's clear that he's spent a lot of time pondering what makes development really work. I also like that his advice obviously comes from someone who's been "in the trenches", understands real-world commercial development, and lives it each day. The series on the "22 Immutable Laws of Marketing" is a great example of his ability to break down software-business issues for the pocket-protector crowd.

This latest MSDN article is a good summary of things to look for when hiring developers into your team. What I really like is how he refers to "shrinkwrap qualities" -- those qualities that differentiate a good programmer from a good commercial-product developer.

My own experience is that there are lots of developers who pay lip service to OO design, architectural consistency, reuse, current documentation of all kinds, and so on -- but not all developers maintain that discipline day-in and day-out. And an even smaller percentage of those have the "shrinkwrap qualities" -- the ever-present understanding that what they're writing will eventually be in the hands of a paying customer. And while a well-designed, elegantly implemented software product is important (especially for the on-going maintenance and evolution of the product/product line), the end-user just wants an application that helps them get their job done and make their life easier.

Go forth and subscribe.

So I've had a seller's account on Amazon.com for years. Michelle and I often put up books we're done with or CDs we no longer want. You get an email when someone bought something from you (via the "Used & New" links on each product page) and then you have a couple of days to get it in the mail. Sometimes, after we've done some spring cleaning, that seller account can get up to a few hundred dollars.

Every 4-6 weeks or so, they transfer it to your bank account and send you a nice little summary of the transactions. Then you've got some side money with which to get more books, CDs, or movies... right? So where should you go to spend that money?

Well, what they DON'T offer is an option to just credit your regular Amazon.com account with the money in your seller's account. I don't get that... all they need is to provide a "Convert this balance to an Amazon.com Gift Certificate" option and they'd often get that money right back. Doing that leads to potentially three transactions that make money for Amazon -- My initial purchase of an item, their fee for me selling that item on their site later, and then another purchase using the proceeds from that sale.

I've emailed them about this before (have fun finding an email address on their site), but just got a boilerplate "thanks for your suggestion" response... so, what am I missing?

Andy Hunt and Dave Thomas, authors of The Pragmatic Programmer, did an interview with Artima last year and somehow I missed it until this afternoon. Great stuff here, but the part I enjoyed most was right up front when they talk about craftsmanship and how easy it is to fall into a trap of "I work on this piece and only this piece" on large projects. They refer to a quarry worker's creed -- We who cut mere stones must always be envisioning cathedrals.

The idea, of course, is that even those who work on small pieces of a much larger puzzle have to have the big picture in mind. Without that, the result is a finished project that lacks an overall, complete vision. Ok, so your part of the application is the database design, or the exception management, or the communications layer -- all are parts of a larger work that couldn't be built by any one person. Work on the stones but think of the cathedral. Take pride in your gargoyle.

The interview is well worth a read.

On that last post, I started to think about the similarities between my approach to code samples/mini-projects and my approach to organizing favorites/bookmarks. I'm pretty religious about "collecting" bookmarks for cool things I come across. With .NET articles, in particular, I've got about 15 different sub-folders under which I store bookmarks. Those sub-folders are for things like CLR, Exception Mgmt, WinForms, XML, SQL Server, Threading, Unit Testing, and so on.

I've got a pretty good collection of many different articles, from MSDN articles, blog articles, and other sources... the thing is that I'm really bad about going back and referencing them. Instead, when I'm on a project and need some info about a topic, I again go to Google.

Is storing all those favorites in Firefox a waste of time?

I really need to figure out a good way to organize code samples and little "test" projects. On my data drive, I have a folder called \download where Firefox puts all my downloads. Over time, that folder grows pretty large and I have no idea what some of the .ZIP files in there are. Often, I'm downloading code samples and utilities to look at but I need a good way to organize the stuff I want to keep.

I've started setting up a "Code Samples" directory structure, with sub-dirs for "WinForms", "WebServices", "XML", CompactFx", etc... but I'm not sure if that's going to be useful.

And a big part of me thinks I should just delete all but own little "test" projects... for all the little downloaded samples, there's always Google.