I've always had trouble with TDD. I'm a mostly self-taught dev, and I had my first jobs in high-velocity startups that themselves were made up of engineers who'

I've always had trouble with TDD. I'm a mostly self-taught dev, and I had my first jobs in high-velocity startups that themselves were made up of engineers who'd prefer a quick-and-dirty approach. Later in my career, I've worked for more traditional software businesses, but they didn't encourage testing either. It was always an afterthought, and time was better spent on building flashy and fancy new features to pacify customers. When I founded my first bootstrapped businesses, it was the same thing: things had to be built quickly, almost always as easily scrapped experiments. A SaaS that is well-tested but missed it's market opportunity window was something I didn't want to risk. Even with the SaaS FeedbackPanda that finally worked out (and which I sold with my co-founder last year), testing was more or less non-existant. We truly tested in production, and trusted the infrastructure and framework choices we made to bear the most of the burden. It worked out for us, and even our acquirer didn't expect much in terms of TDD in the properties they were looking for. I have the feeling that the concept of rapid prototyping has developed into a cultural phenomenon that expanded into software engineering—and people have adopted to it.