Behind the Compiler
"What will happen behind compiler?" is my favourite questsion when dealing with technical design and coding. There are many cool and powerful things we can use to be more productive, faster and better. We have automatic properties, extension methods, partial classes, generics and so on. If we don't know what they are and how these things are handled by compiler we may face serious troubles later.
When I plan to use some new features of language, in my case mostly C#, I will read about those features and then I will check out what happens when I use them in my code. I try to find out what these features really are - are they something really new or are they something that doesn't exist after compiling. After that I can be sure how and in which context to use these features.
One of my favorite examples is n-tier architecture using partial classes. Suppose you have a project and you have to implement BLL and DAL. Some other guy is building presentation layer. So you sit down and write partial class - one part for BLL and the other for DAL. And this class works in context of one business object and it's operations. After two weeks you have many classes like this.
Now, guess what - your application doesn't have 3-tier architecture. Why? Because after compiling you have two times less classes than you can see in IDE. There is no such a thing as partial class behind compiler. If your BLL and DLL soup had Presentation layer same way with them then after compiling you will have legacy style fat client.
There are some very valuable tools you can use to check out the results of compiling. My favourite ones are ILDasm and Lutz Roeder's Reflector. If you are not sure what one or another feature is after compiling then use these utilities to find out what compiler built.
I strongly believe that knowing your language and knowing your compiler the best you can is one of the golden keys to your success as developer.