Context:
There's something you don't understand about your code. (Typically you don't understand its behavior ... it's doing what you told it, but not what you want.-) You can try to match your mental model of the code to the code itself, but you may fail, or you may fail to do it quickly.
Therefore:
Ask the code. Set a breakpoint and find what the value really is. Set a breakpoint (or two) and find what the flow of control really is. Set a breakpoint and find how (and if!) the program gets somewhere. Maybe don't set a breakpoint, just type some code into your debugger and run it.
Known uses:
Extreme Programming in the Chrysler Comprehensive Compensation project.
See
www.XProgramming.com 
and
www.XProgramming.com
The best way to ask the code is build a unit test case. The first iteration will fail because you don't know what the result will be. Once you get a value back, you need to think about if it's the right thing or not. When you're finished, you have a test that shows exactly what the code does.
Also Known As:
"Star Wars Consult" and "The Jedi Way"
(in the immortal words of Obi-Wan Kenobi: "Use The Source Luke!")
By Using the Debugger
I've been applying this to my own work in Perl and C++.
(It's easier in Perl, where the containers are more visible to the debugger, and I can type more code in the debugger).
Heh. I just spent an hour trying to ask the [C++] code, "How is this variable initialized?" I just realized; the code's inability to answer ... was an answer. (The variable needed to be zero, and had been; until I changed from a global variable, where all fields are guaranteed to start as zero, to a dynamically allocated variable, where they aren't.)
At that point, the student achieved enlightenment.-) --Paul Chisholm
Also related to Debugging And The Scientific Method. As Donald E. Knuth (Don Knuth) supposedly once said:
Beware of bugs in the above code; I have only proved it correct, not tried it.
I was curious about this and looked on Knuth's web page. He writes http://www-cs-staff.stanford.edu/~uno/news98.html www-cs-staff.stanford.edu: "More than a hundred webpages ascribe that quote to me, and it sounds like something I might well have said. But lately people have been asking me for the authentic source, and I've totally forgotten where I wrote it. Probably not in a published paper, since I've written few papers in the first person that include untried code. My best guess is that it was in a letter I sent to somebody. So if you were that somebody, or if you have any other clues about the source of that line, please let me know."
He got an answer: see www-cs-staff.stanford.edu . --Dan Schmidt
This is a bad practice to rely on. It has it's place of course, but coding with the debugger often leads to bad code. The reasoning (in my experience) is you don't understand the flow of your code for any case except for the path the debugger shows you.
When I come across a problem I try to follow the code thru in my head. Mentally debugging if that makes sense. Often I will catch the bug immediately. Only if that doesn't work do I Ask The Code . Gareth Lewin
By Other Means
This principle applies outside of software, too. In How Buildings Learn, Stewart Brand quotes an MIT animal physiologist who told his students:
The animal is always right. When in doubt, ask the animal.
That could be extended rather poorly to:
I am always right. If you doubt that, just ask me.
Is this the same as Ask The Computer?
It is closely related to Ask The Computer, but Ask The Code focuses on looking at the source code, while Ask The Computer is about looking at the results of execution.
Another way to Ask The Code is to search it (with grep or an equivalent)
See original on c2.com