Exactly. I write my programs/systems a few times. Each time I discard the previous version and start from scratch. I end up writing code that's easy to test and easy to swap parts if needed. I also know what TDD brings to the table. On top of that I have over 15 years of professional experience... so I usually know how to write software that complies with what we usually call "good code", so TDD offers me zero help.
For more junior engineers, I think TDD can help, but once you "master" TDD, you can throw it out of the window: "clean code" will come out naturally without having to write tests first.
I was taken by TDD for about six months, years ago. I always felt that I was never good at it because edge cases I hadn’t thought of came up or the interface wasn’t actually the best/cleanest/most maintainable way to write that code.
But it got me thinking about testing while writing the class instead of shoehorning a class into a test just before the PR went up. That’s what I think my takeaway was. To this day I think about not just how clean/maintainable the code is, but also how testable the code is while I am writing it. It really helps keep monkeypatching and mocking down.
For more junior engineers, I think TDD can help, but once you "master" TDD, you can throw it out of the window: "clean code" will come out naturally without having to write tests first.