In the first five years that I was working as a developer I didn’t once bother to read the .NET framework source code. I’m going to go out on a limb and say that this is probably the case for most software developers. We work with the .NET framework and associated tools and libraries every day, but we seldom care about how they really work or what’s contained within. Now, don’t get me wrong, the whole point of a framework is to shield you from having to know the underlying implementation details and knowing the entire framework is not necessary. I would argue though that knowing parts of the framework and how they work opens up opportunities and affords certain benefits.

Improved Ability at Reading Source Code

Being able to read someone else’s code is a big part of being a software developer. Unless you are a one man shop, you are almost certainly going to be forced to work in someone else’s code or at the very least be able to read it and understand it. Like everything else, reading code and understanding it quickly is an acquired skill. The more practice you have at it, the better and faster you become. Reading the .NET source code is a great exercise that improves this skill and gives you a window into what you are working with on a daily basis anyway. It is often the case with software developers I work with when consulting that they are very comfortable with their own code. They like working with what they know, and more often than not, they tend to shy away from having to jump into an area of the system they aren’t familiar with. If you aren’t working as a consultant and frequently jumping into new projects then you are in danger of becoming comfortable in your own code. Reading the .NET source code is a way for you to avoid this situation. Don’t stop there though, go and read the code of the third party libraries you work with too like Fluent Validation. I promise you will find it enlightening and rewarding.

Customization

Knowing the underlying source code affords you the opportunity to create custom solutions you might otherwise not be able to. My work with RequestInjector is just one example of this. The .NET Core framework is powerful and flexible out of the box, but it’s impossible to foresee all the different ways it could be used. That’s why they built in extension points. It’s hard to understand all of them, or to even be aware of them for that matter, without going and reading the source code. Another example is when I needed to push request values through on every request into Fluent Validation. I could do it manually over and over again, but that’s not very fun. If there’s one thing I hate it’s explicit, repetitive code. Work smarter not harder. So what did I do? I went and read the Fluent Validation code to see how it works and where I could create customization within it. In my case this ended up being in one of the factories that creates the validators. There’s a component of creativity to our work and understanding the source code enables creativity where it might not otherwise be possible.

Faster Debugging and Problem Solving

It is much easier to fix issues in development if you know what the framework is doing underneath the hood. Sure, you can go type your error message into Google and hit up stack overflow in the hopes that someone else has hit the same error message too and has a nice cut and paste solution for you. Knowing how the framework behaves, and more importantly how it was designed and why, gives a deeper understanding of what you are doing. This by itself often times allows you to avoid problems in the first place. In depth knowledge also allows you to help those around you when they run into issues.

Exposure to Practices and Technologies

Finally, by reading other’s source code you are gaining insight into the practices and technologies that person or organization uses. That in itself is worth gold in an industry built on knowledge. Case in point, I’m currently reading through the source code for .NET Core DependencyInjection. In going through it I came across something called BenchmarkDotNet which they use to bench mark the performance of DI in .NET Core. Up until then I had never heard of it and it would have been really useful to know about when I was benching RequestInjector. Not only that, but I have full example code since I have full access to how they use it at Microsoft in the .NET Core source code. Think about all the different libraries and frameworks out there and the amount information each one of those contains.

Do yourself a favor, read through other people’s source code. There’s no down side and you have everything to gain.