Sitting at your desk and checking. This can be in preparation for a CodeReview, PlayingTheComputer on your own code, or a form of PassiveDebugging.

----
* Pros:	CodeReview prep: Assuming that it's faster to read code that to have it read to you, reading, listening to, and smelling the code at your desk will logically be more productive than being exposed to it for the first time at a meeting.  It also makes the CodeReview''''''s more productive, since all the participants have freshly gone over the code. (See also: ListenToTheCode, CodeSmell''''''s)
** It gives you a chance to concentrate at the task at hand (inspecting the code for errors) without trying to ''fix'' each error as you find it.  Definitely conducive to flow. -- JeremyCromwell

----
* Cons:	If you know what the program is supposed to do, '''test''' whether it does it rather than '''convince yourself''' that it does it. The more complex the program, the more valuable this advice. After all, if you were a perfect programmer, you wouldn't be considering desk-checking.
**''(I assumed the desk checker is looking for errors, not trying to convince himself of their absence. Machine testing complex programs can easily become an intractable problem, and meanwhile the machine won't tell you that '''the program is too complex,''' whereas a very quick desk check can.)''
** If you don't know what the program is supposed to do, then it doesn't matter.
----
* Other: "it doesn't matter" ''Unless one wants to know, as on occasion, I do!'' But most often I am interested in Why it needs to do any thing at all, as well as, why is this a thing that needs to be done. -- DonaldNoyes.20110312