Someone asked Raymond a question (that dealt with MFC code that he’d never seen or known the workings of) and he solves it by going to the code (which the person asking has access to as well).
Honestly, that’s what you have to do sometimes. In a perfect world, every system will be 100% documented (and the documentation will be easy to find… which is half the battle). But how often does that actually happen? In this particular case, part of the question *is* documented and clearly available.
The code will always tell you exactly what the system is doing (not to be confused with what it *should* be doing), and the code never lies. Every developer should be capable of finding answers to their problems by reading the code in question, assuming they have access to it. I know that sometimes you really just want the answer in a quick way (after all, time is money and all that), especially if someone knows the answer off hand. But you’ll be more knowledgeable about the system you’re working in, in addition to being able to honestly say you’ve looked as deep as you could to solve your problem. You might even find bugs!
Much of the time that someone asked me a question about our system I end up… looking at the code. I’ve done it enough times that I happen to know where to look but I don’t necessarily know the answer off hand. But when I started out, I had obviously never seen the code base (in fact, I’d never even coded in the language it was written in) but reading the code taught me the system. Often the reason I was in the code was to troubleshoot a problem, so I had to figure out what the system was *supposed* to be doing, so that I could make it do that.
Perhaps a new phrase is in order, RTFC. Note that that ‘F’ in that phrase should never been taken as harshly as the spoken version actually sound, but if you can’t help it… RTC.
Update: Apparently RTFC has been coined previously.