TDD has some excellent philosophy behind it, but I struggle to implement it because I get discouraged by failure, and move on to other topics. If the TDD appro

TDD has some excellent philosophy behind it, but I struggle to implement it because I get discouraged by failure, and move on to other topics. If the TDD approach said "thank you" for the good parts (code structure, not breaking 500 other test cases), that would make the 13 errors less scary. One of the things I like about software is that it's "soft" - it should be possible to make changes without the fear of getting it wrong, and be able to fix them now while I see the problem, rather than procrastinating until later when I've forgotten about it. The same "thank you" system applies when working with external contractors (e.g. language translations). We can assume they tried their best, and therefore might not know what else to say. Reporting 19 problems will get us a reputation for being nitpicky, hostile, even toxic. Rather, we should thank them for the 730 that they got right, and suggest improvements for the 19 that we think might be better. With thankfulness and encouragement, TDD could really change the industry for the better.