If you write the test after you've written the code, it's much more likely that you'll write the tests that will pass what you've written.

That's just how our brains work.

If you determine the criteria for whether a decision is good after you've already made the decision, it's much more likely that you'll create criteria that justifies the decision that was just made.

That's just how our brains work.

Determine how to assess whether something is good before you implement it and/or before you make a decision.  Otherwise, you will tend to be emotionally attached to what you just did, what you just decided.

http://jchyip.blogspot.com/2011/09/criteria-first.html

My Top 5 ways to reproduce a "Hard to Reproduce" Bug! - http://software-testing-zone.blogspot.com/2007/05/my-top-5-ways-to-reproduce-hard-to.html

Common TDD issue and suggested solution - http://www.agileadvisor.com/2008/10/automated-test-problems-address-root.html 

http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment

http://www.notesfromatooluser.com/2008/11/misconceptions-with-test-driven-development.html

http://blog.goyello.com/2011/08/29/what-does-tdd-mean/

https://juristr.com/blog/2014/05/told-you-that-testing-is-a-waste/

https://www.thoughtworks.com/insights/blog/test-driven-development-best-thing-has-happened-software-design

https://itnext.io/test-driven-development-is-dumb-fight-me-a38b3033280c

Does this mean I think you should skip TDD for programs you’re going to run once and then throw them away?

Well, I’m closer to OK with that than I am to the other cases here, but I often spend enough time editing and rerunning to make me think there was probably a central bit of the program that would have benefited from some TDD.
https://ronjeffries.com/articles/020-01ff/when-not-to-tdd/

What TDD is -- and isn't -- like. - https://ronjeffries.com/articles/020-01ff/what-tdd-is-like/