> What kind of software are you writing that this works? full-blown TDD-as-a-specification is both too detached from the domain and too bogged down in details at the same time; you end up creating a Frankensteinian codebase that barely makes a coherent whole, but it's sure easy to test.

For clients, where I most often practice TDD? Libraries. Web applications (mostly services, occasionally web). DevOps tools. Personally, where I do it for core logic when I understand the problem fully going in? I have a React Native app in the Play Store which I basically proved working via tests before I ever built a UI. I've built a service-oriented authn/authz stack I'm looking to open-source soon, and it has 100% test coverage and the test cases have been looked over by much wiser heads than me to bulletproof it. All sorts of stuff. I naturally write code that's decoupled sufficiently to avoid mocking (except when forced to by writing sufficiently downstack stuff, but that's rare enough these days).

Specifications are in English from the client (either from them directly or written by me to their approval), I turn them into tests as I rough out an overall architecture, and I then make those tests turn green. And, because I actually know how to write tests in the large and in the small, I have a reasonable--not perfect but reasonable--expectation that my code will work.

(I don't do this as much as I should for personal projects, but that's because most of them are much more exploratory or are effectively plumbing over somebody else's API.)

> The thing that I believe 'SadWebDeveloper is aiming at is that hippie-devs mistake finger for the moon; they think of TDD and CI and other popular practices as dogmas to follow, instead of potentially useful techniques that may or may not be beneficial to any particular project.

This is the sort of in-your-own-head view that makes one old prematurely and unnecessarily both unwise and unlikeable.

I know that, because I used to say what you do, and I was wrong. It used to be Ruby, though, not just JavaScript. Things change too fast. It's all too reckless. Then I started using them in earnest--first Ruby a few years ago, then Node and JavaScript over the last year. And I realized that the things that draw external criticism are things that exist for a reason. These things are not discussed merely because they're "popular", it's because they make the end result better and they are transferable from project to project in a way that amortizes the cost even for small ones.

But, more importantly, the notion that these are somehow "hippie-devs" because they care about practices you don't is one, disrespectful, and two, kinda really often wrong. (I know this because I thought this, and I was full of shit.) These are not stupid, uncritical, or foolish people. There are problems and there are gaps--the Node ecosystem's general lack of understanding of underlying Unix is continually troubling--but when it comes to the platform and the practices of it, the notion of "change for change's sake" is mostly unfounded.

Anyway, the software ecosystem around the web is bonkers because the web is bonkers. Because people want the web to do stuff it wasn't built to do and is really hard to do effectively. That's why there's so much churn. Because people are learning new things and applying them. (Heaven forfend.) But it's working. If you step into this stuff, today, here and now, with React and ES6, you get an experience that is flat-out better than any I have had with any system, ever--with WPF being the closest, but not that close, I can think of, and miles better than any server-side HTML chewing that I can think of. Stuff is changing because stuff is improving. And it's also slowing down as practices gravitate towards what appear to be reasonable local maxima. It did for Ruby, it is now for JavaScript; you can write a frontend using React and be reasonably assured that it'll be supported for most of a decade and that you'll be able to find developers, and the JavaScript backend stack hasn't really changed much in a couple of years). It's part of the lifecycle. Whining about it is whining about the weather; nobody else cares, and nobody wants to hear it.

I run a devops consultancy. Sometimes this is marriage counseling for engineering teams; sometimes this is "come provide technical leadership." I am paid to have opinions and to lead people towards best practices. I have learned over time that holding those opinions so tightly that you say "fuck all JavaScript/NodeJS developers" doesn't make you good or wise or experienced or decent, it makes you a jerk, and it makes you unfit to interact with people, let alone mentor young adults. And it is unworthy of your defense.