No, because I very rarely do algorithmic stuff that would benefit from unit tests.
When I start to build something, I don't exactly know how it will work and what the output will be.
When I start to build something, I don't exactly know how it will work and what the output will be.
If you don't know what to test, then you don't know what you are implementing. Find what that is, clarify it and pin it down with a test then move on to the implementation to make it happen.
If you don't know what the output is like, then do some exploratory throw-away work to know a little more. Then write the test that you would've written if you knew what the output is like.
tackle your problems one a at a time, not knowing what to test is not a good enough excuse to not test first.
Make it Work - Make it Right - Make it Fast (while still under the protection of your first-written test)