For almost a year now, I’ve been writing a book about debugging and problem-solving in .NET. I’m pretty upset at whoever said writing a book is just like writing a series of blog posts. That was way more work than I signed up for. But it’s over now and my book Practical Debugging for .NET Developers is available. This book is all about solving bugs. I daresay say that the ability to solve difficult problems is what differentiates great engineers from good engineers.

The Immediate Window looks pretty straightforward, but it hides some cool features. In this post, I’ll show you five tricks you can use with this window that you absolutely should know if you want to debug faster.

We are constantly dealing with libraries and NuGet packages. These libraries depend on other popular libraries and there are a lot of shared dependencies. With a large enough web of dependencies, you'll eventually get into conflicts or hard situations. The best way to deal with such issues is to understand how the mechanism works internally.

In this article, we'll see how GC activity can cause major performance problems. This phenomenon is called Memory Pressure and we'll see how to deal with it using memory profilers.

Memory leaks are very common, hard to notice, and eventually, lead to devastating consequences. The main tool to detect and fix memory leaks is a Memory Profiler. In fact, I believe the most common usage of memory profilers in .NET is exactly for the purpose of fixing memory leaks. In this article, you'll see exactly how to use memory profilers to find the leaky objects, why they are still referenced, and how to solve the problem.

Memory leaks and GC Pressure cause pretty inconvenient effects like out-of-memory crashes, performance problems, and high memory consumption. Our primary tools when dealing with those issues are memory profilers. They are one of the most important category of tools in .NET troubleshooting, and in this article, you'll see how to use them and extract the most information from them.

What happens if you’re working on something that lasts much more than one sprint? Maybe 3 sprints or 10. Are you going to work on a separate branch, ending with a huge merge? Are you going to run automated tests on that branch? This matter is not that simple, as I recently experienced.

Is C# slower than C++? That's a pretty big question. As a junior developer, I was sure that the answer is "Yes, definitely". Now that I'm more experienced, I know that this question is not obvious and even quite complicated.

When it comes to debugging software, tools are extremely important. Get the right tool and you extract the right information. Get the right information and you can find the root cause of the issue. Find the root cause and you've solved the bug.