Puedo darle una respuesta que se ejecuta en ambos sentidos.
Por un lado, no hay nada como las buenas habilidades de lenguaje ensamblador para enseñarle cómo funciona realmente una computadora. MSIL es, hasta cierto punto, un lenguaje de ensamblaje. En el lado negativo, hay muy pocas oportunidades para hacer este tipo de desarrollo.
Por otro lado, recurrir a mirar el MSIL para solucionar un problema no es necesariamente la manera más directa o educativa de comprender un problema. En cinco años de programación de .NET, nunca sentí la necesidad de ir allí. Solo una vez un compañero de trabajo (que había trabajado en Microsoft en pruebas de compilación) se fue con un problema que yo estaba tratando de resolver, y al final, su respuesta fue engañosa, porque el problema real se basaba en el diseño y las limitaciones de CLR. . Un mejor conocimiento del CLR y C# habría llevado a una mejor comprensión y una solución real.
(En caso de que se lo pregunte, el problema era que quería usar "como" para el casting seguro con un genérico. "Como" no funcionó, pero "es". Mi compañero de trabajo notó que "es" y "como" usan el mismo MSIL. El problema real es que "como" solo funciona para las clases de conversión, y sin la restricción adecuada en la declaración genérica, C# no sabe si su tipo genérico será una clase. De hecho, los tipos que usaba con genéricos eran tipos de valor; "como" no podía funcionar para nada.)
En lugar de ir por las habilidades de MSIL, recomiendo el libro de Jeffrey Richter CLR via C#. Incluso después de años de excavar difícil en C#, este libro todavía está lleno de revelaciones. Aprendo algo de cada página.
Haha, "¿Dónde puedo obtener más información sobre estas cosas e impresionar a todos los que me rodean". Esas son dos * preguntas completamente * diferentes, mi amigo;) A menos que salgas exclusivamente con nerds (como yo), supongo ... –