confessional debugging

confessional debugging (uncountable)

1. (informal, rare) The debugging technique wherein a programmer explains a problem to someone else, and in the process realizes the source of it.
   • 1993, Steve McConnell, Code Complete: A Practical Handbook of Software Construction, Microsoft Press, →ISBN, page 635,

     Talk to someone else about the problem. Some people call this “confessional debugging.” You often discover your own error in the act of explaining it to another person.

   • 2001, Paul Litwin, Ken Getz, and Mike Gunderloy, Access 2002 Desktop Developer’s Handbook, John Wiley & Sons, Incorporated, →ISBN, page 948,

     There are two more bits of strategy you might want to consider. Many programmers find “confessional debugging” to be one of the most useful techniques around. Confessional debugging works something like this: you grab your printouts and go into the next cubicle, interrupt the programmer working there, and say, […]

   • 2004, James P. Cohoon and Jack W. Davidson, Java 1.5 Program Design, McGraw Hill Professional, →ISBN, pages 672–673,

     If you have worked at a help desk, you have probably experienced the phenomena^[sic] known as “confessional debugging.” A person is explaining the problem and as they do so, it suddenly dawns on them what the problem is. The act of explaining the code to someone makes you think a little more clearly, not skip steps, and so on. Confessional debugging is surprisingly effective.

   • 2004 May 25, “Mary K. Kuhner” (username), “Re: rec.arts.sf.compostion FAQ”, in rec.arts.sf.composition, Usenet,

     Programmers call the computer equivalent "confessional debugging." "Hey, Eric, can you look at this code? I can't understand why it doesn't--oh! Never mind."

While the concept of confessional debugging is widely recognized among programmers, the term confessional debugging itself is not as common.