When I first learned about TDD I thought the same (order of test and implementation does not matter that much). Yet when you do the TDD steps
* write a failing test (RED)
* implement minimal functionality so all tests pass (GREEN)
* REFACTOR
and overcome the initial revulsion you will get a ton of benefits that you didn't know existed. I'll first give a few that are more on the code quality side
* You have a complete test suite, without redundant tests
* Tests are usually not that mock-focused [] as the implementation-after-test didn't introduce random roadblockers for testing.
tests do assert the relevant properties (tests-later code bases often have code bases that don't assert much or properties you don't care about).
* When you write your test first, you basically write a small example how it feels like to use the API you have in mind for solving your problem. This drastically improves quality.
Some non-technical benefits of TDD
* I find TDD helps me tackle bigger code-pieces where I just don't know how to start implementing.
* TDD is programming gamification. You are rewarded with regular, small successes of having added another test and made it green. So whenever you ask yourself: OMG, have I made any progress in the last 3 days, you can actually tell: Yes, I added 15 tests and made them pass - I objectively got closer to implementing that feature.
* Not an issue where I work, but have often heard about this from other places: If tests are there first, no one can tell you to not spend so much time on writing tests. TDD-style is protecting your boss from shipping that car without having the brakes checked.
* The same line: TDD gives explicit room for refactoring.
[*] obviously one cannot avoid mocking especially when dealing with resources external to your code base, yet I have hardly seen TDD-originated tests that mocked