FWIW: I don't do tests because of how I learned programming writing large swaths of code for weeks that had then to work perfectly the first time (embedded C on a machine with very poor development process and external company that had to sign the binary before I could run my code). I taught myself rigorous thinking about code and various techniques that make it less likely that there is something wrong with it, otherwise I would be loosing a week before I got another chance to run it. I also then worked in a lot of projects with poor code quality and no test coverage that I had to run extensive refactors of and keep hammering on until it looked decently. With this in mind, unit tests have never been useful to me in any way and would be just a waste of time because they would not bring any benefit to anybody else I worked with.
It is not that I believe tests do not work. Tests is a viable solution to a problem. The issue with tests is that you have to do a lot of things right and you have to structure your development in certain way for tests to be productive. And if you don't do a lot of things right then tests will just cost a lot of development time without much benefits.
Introducing unit testing is hard if your team isn't already doing it and costs a lot of effort for practically no immediately visible effect to stakeholders.
Very few organisations I worked in would be at maturity level when investing in unit testing would be the highest return on investment thing you could do at the moment. There is usually many other problems that cause less disruption to development practices and bring much more benefits than unit testing.
On the other hand I am a huge fan of functional testing where you create a test harness that ensures that public interface of your product (application) functions as expected. The effort is much smaller (you only evaluate public interface which already is integrated with other things and which isn't expected to be changing a lot anyway), the benefits are clearly demonstrable and understood by stakeholders.
In my experience, new teams just tend to rewrite everything anyway. We have this cultural delusion that we write code for posterity when in reality it rarely lasts more than a couple years no matter what. Technology changes too quickly.
It is not that I believe tests do not work. Tests is a viable solution to a problem. The issue with tests is that you have to do a lot of things right and you have to structure your development in certain way for tests to be productive. And if you don't do a lot of things right then tests will just cost a lot of development time without much benefits.
Introducing unit testing is hard if your team isn't already doing it and costs a lot of effort for practically no immediately visible effect to stakeholders.
Very few organisations I worked in would be at maturity level when investing in unit testing would be the highest return on investment thing you could do at the moment. There is usually many other problems that cause less disruption to development practices and bring much more benefits than unit testing.
On the other hand I am a huge fan of functional testing where you create a test harness that ensures that public interface of your product (application) functions as expected. The effort is much smaller (you only evaluate public interface which already is integrated with other things and which isn't expected to be changing a lot anyway), the benefits are clearly demonstrable and understood by stakeholders.