Untitled Coding Blog

Over the past years I had some interesting experiences at work, interesting as in not bad, and I learned some curious facts about working as a team on features from their technical design to coding them. I am not a technical leader and  I didn't implement any of these concepts, I just noticed them. But I still need more experience with these. That's why I am writing about this. I also have to do a presentation about this and this post is a bit of practice for the presentation. There might be other better approaches, but currently this is what seems best to me. So I had to work on the same team with two different approaches: one in which a single person was designed as a technical lead making all the important decisions and the other in which there was no person that made all the technical decisions. In the first approach that person had to come up with the entire technical solution for something and all the other people had to follow and code that design blindly. In techn

A couple of months ago I had the chance to look a bit into the famous CoreCLR source code and actually compile it. It took me a while to understand it and how use it. This is probably some really advanced stuff that most of the time you don't need to know. It is actually composed of 2 main parts. One is the actual virtual machine which takes and runs the intermediate language code. The other part is the actual core .net library called "System.Private.CoreLib.dll" with the base types such as the string type or the numeric types. The second  These 2 parts are strictly related together. They need to have the same version and build type, release or debug. The second part that contains the source code for the core type in .Net is actually a separate assembly written in C#. The unusual thing here is that people expect the types to be in "System.Core.dll" but it's not. That assembly is just a stub for the real assembly containing the actual implementation for the