Question: Could anyone elaborate what work you are doing in garbage collection in daily corporate work?

How much your considering garbage collection in your SDLC?

Answer: 
The advantage of Garbage Collection is that you **don't** have too worry about it much or at all. You lower level implementations can be planned (beforehand or on the fly) easier, having more time to worry about other complicated issues, not having to take into account freeing up memory.

There are some things to keep in mind to take advantage of Garbage Collection, but they are usually easy or intuitive. A couple examples:

* You might have to change your thinking to take advantage of the fact that **circular references are not really a problem** any more (as long as all the resources involved are managed of course). This is pretty easy and fun to get used to!
* It's helpful to define variables in the lowest scope possible. But, you'd want to do that *anyway*.

So, if you're moving to .NET from someplace without managed memory, yes, read about GC a bit, but if you find yourself not thinking about it, *that's the point*, don't worry.

**Edit**: Keep in mind you can still used *unmanaged* resources in .NET. Even in many of the common .NET namespaces, unmanaged resources are used underneath. You must understand the `.Dispose()` (and corresponding `Using` keyword) as clues that you're stepping into unmanaged memory. ([see me blab about that here.](https://stackoverflow.com/questions/2334521/usage-of-a-using-statement/2334604#2334604))
My main concerns, for daily corporate work, in terms of garbage collection is making sure we have a good janitorial service. ;)

Really, for the majority of LOB applications, you probably never need to worry about garbage collection. If you find you're having a performance issue, and profiling is showing that you have memory related performance issues or a memory leak, *then* looking at the GC perf is useful. This is rare in typical LOB apps.