The number 1 way to write untestable code - is to build your entire project without writing tests at all. Adding tests after the fact will make you want to kill yourself, whereas when you write tests either before or at the time of writing you will generally take the path of least resistance for writing code that can pass those tests.
With that kind of take, I'll raise with "write untestable code by writing for only you and only current you."
I'm often surprised how thoughtful past me was with code, knowing how people might try to screw it up. Even to the point of having useful and sometimes fun error messages. Feedback from other people agrees with that assessment.
Not the parent’s author, but I tend to write extensive tests from the very beginning. Sometimes they are indeed annoying while refactoring, but more often than not they are very helpful in ensuring that the whole thing still works.
And if the tests are annoying that’s usually a sign that they can be improved.
Personally, I don't do much refactoring. If I'm exploring a new idea, I write tests after I've experimented a bit and have a good idea of what I'm going to build - and then write mostly integration tests with very few mocks (usually only calls to external services). I don't refactor until I come back to add features, and yes, the tests help immensly.
How much experimenting do you do? You could take that as far as writing it once without tests (experimenting). Then write test for what you created. Then start over and keep the tests.
