[gbog]

I found it useful to start writing an email to some people concerned. I usually start with "it don't work", then because I don't want to look stupid I explain a bit what doesn't work, I feel the need to explain my thought about why do I don't look like unimaginative, and then I write down how I would check if I'm right, because I don't want to look like I'm not scientific, then I just try the test because I'm not supposed to be lazy, and then usually I trash the email because I found the bug.

[allannienhuis]

This is one of the reasons I like to provide detailed commit messages, and encourage my team members to do the same. I treat the commit message like a short email to the team (even if that's only future me) about why and how I made the change. Summarizing the change in writing often uncovers logical flaws or missing edge cases. I've aborted my commit (after copying the notes for reference) more times than I'd like to admit when I've realized that I've not thoroughly tested something or missed updating that admin report that would be affected, etc. The act of 'telling someone' exercises different pathways in the brain and helps you think about the problem differently. As someone already pointed out - it's a flavour of rubber duck programming. It also works really well in a team environment where your CI system emails the whole team the commit notes. You get a low ceremony quick design review. "Did you update the X system/form/report when you changed Y?" replies happen more often than you think, and junior devs can actually learn a lot about an existing system just by seeing the approach used by other team members.

[tanzam75]

It's also a miniature version of literate programming. You can go through all the commits and get an explanation of how the program evolved -- not just the actual lines changed.

[penguat]

sort of the equivalent of rubber duck programming? I've been known to do that a few times.