I do follow it (almost every time) for bug fixes: first write the test which repro the bug....
But for new development, I try to be tdd-ish, depending on the use case, but definitely not by the book, and on purpose.
Rather than writing a long comment, I’ll quote John Ousterhout (Philosophy of Software Design, chapter 19.3 about unit tests:
The problem with test-driven development is that it focuses attention on getting specific features working, rather than finding the best design.
— John Ousterhout, A Philosophy of Software Design (19.2, p154)
And that’s it. If we follow TDD: we should stop as soon as we get working code. On the other hand, I believe working code is not enough when you strive to build good design (this is even the whole chapter 3 of John O’s book mentioned above: Working code is not enough, tactical vs strategical programming, and one of the 15th design principles he lists.)