A: Give him a bottle of shampoo with the directions, "Lather, rinse, repeat."
Debug asserts are a tough sell. Lots of developers have never heard of them, so they don't use them. Lots of other developers have heard of them, but don't understand them and use them incorrectly. And some developers have watched the second group misuse asserts for so long that they've decided asserts are evil and should never be used at all. That's unfortunate, because when used correctly, asserts are one of the most powerful and cost-effective tools in your arsenal for detecting bugs and pinpointing their source.
The great thing about debugging with asserts is that they do a large part of identifying the problem for you. Once you get the hang of them, you'll often be able to solve bugs by just dropping in a bunch of asserts in the relevant area of your code, and then waiting for an assert to fire the moment your code steps out of line. Then you'll know the exact line that the error first appears on. It's not always quite that easy, of course, but there's no denying that asserts are a tremendous aid. Most developers don't use asserts nearly as much as they should.
In this chapter, we'll discuss what asserts are, what they aren't, and how to use them to quickly identify bugs at the point of failure. We'll also examine the specific classes.NET provides for asserts, and how to customize those classes for situations where the standard assert won't work.