I didn't the first 10 years. Then the projects needed more coordination (team members), more refactoring, future proofing (making sure one can replace individual parts), dealing with external API and simply having had to deal with too many complex bugs. Apart from very visual projects (HTML layout), all libraries, especially open source, I add some tests.

It's usually not 100% TDD: I write code first code, then tests in parallel or shortly after. Striving for 100% test coverage (there are tools for various programming languages) is hard. Only very rare do I write test first, then code. That would require specification from somebody, or e.g. dealing with an external API.

Was a .NET programmer a year ago. Tests regularly took more than several seconds to run, so it wasn't feasible - the feedback loop was too high.

I'm a web developer now (Ruby on Rails), and I rarely do TDD. The feedback loop is quicker, but I still end up not doing it, and feel guilty for it.

testing paths (integration/acceptance) is N^M complexity (where N is number of function calls in chain and M is the number of significant parameter variants); unit testing is M complexity. writing the unit test first ensures that you know what M is to start with, which makes it much easier to figure out what 'done' looks like

TDD since 1999-ish. If you rarely see anyone doing it in practice, you're in the wrong room :)

I don't.

I don't even write tests... sadly but true

I did before, but now I don't.

Yes