I have never in my life worked for a company that practiced TDD or even met in real life an engineer who talked about it positively, and I've worked for a lot of places.

TDD is an obvious non-starter because it slows you down at the point where you want to be the fastest - trying different designs at the start of your code, and for a host of other reasons.

I'm really not aware of any big companies or famous companies that use TDD, perhaps because it wastes so much time for nothing.

Unit tests are less work than debugging, something I almost never do these days because I have so many tests.

I was laid up for over two weeks in the current project with RSI (from rage-typing to anti-vaxxers, stupid me!) I checked in every day, and here's what I got: "We tried your feature X and it worked great! I wanted to do Y but then I checked your documentation, and it said how to do it."

I would find it impossible to keep up my production rate without rigorous unit tests.

And without design documents! We completely agree there. I start everything with a design document, though the quality of the prose depends on whether I really expect anyone else to read it. But the design is always the best I can do. Even a small feature will get a small design document, even if it's just a paragraph in the Issue report.

However, I do feel that my problems are very different from others, simply because I write a huge amount of code and I demand that it be as close to perfect as possible, which means I have no time to keep going back and fixing things.

You can check out my work if you like! https://github.com/rec/ Except for this summer, the big gappy periods are when someone's paying me to work on their hidden repo.