> Oh that's pretty insightful about SQL, innnnteresting.
Probably a little wrong but interesting food for thought nonetheless.
> Yeah stuff like this gets entwined with engineers' experiences, so you get very subjective takes. Plus, there seems to be some kind of human bug with these things that gets people fanatic about them (see also Agile, DRY, microservices) that then creates a lot of backlash. Like, it'll be hard for anyone to get me to do DDD ever again, just because my intro to it was pretty negative, and no matter how pragmatic or whatever I was in trying to analyze our performance after, our CTO was like "nah we're doing it, please be quiet". I don't know about you but, that doesn't sound like engineering to me.
Well that sounds like a bad atmosphere, but also the people side of things is REALLY hard at work (or in life in general). When someone with authority has an idea and they want to do it, it's probably going to happen and standing in the way of it doesn't do any good most of the time. Sometimes it's even worse and then becomes a personal vendetta thing where they just start perceiving you as a threat to their dominance.
> But that aside, I find that I generally agree w/ DDD. I like coming up with the language of the domain, I like the idea of event storming, I like immutable values, etc. I generally think it maps well to modern web apps, and FWIW people seem to agree, see GraphQL, Redux, and so on.
Yup, I agree -- it's overkill for most apps because the DDD's been done for you most of the time at this point (there was a time where it wasn't), but the DDD promised land is really enticing to me.
> I always come back to construction--there's building and there's building science. When you're building, do things you know work, don't experiment. But in-between or on side projects, try out new things building science has invented, tested, and the industry has productized. If someone came to me and said, "use this ___", I'd say "show me stats, metrics, case studies, examples, comparisons", and then if all that went well, we might start evaluation--on the way to evolving our process. Doing anything else feels like satisfying a different need, maybe that need is important, but it's not the same need as "build things professionally".
Fully agreed... In particular
> how me stats, metrics, case studies, examples, comparisons
This is basically how I judge F/OSS projects and/or new tooling I might use. If you find a project and it has a comparison to it's competitors/alternatives in the README (and clear screenshots/usecase/examples), then I'm almost always sold (then I go check the issues and look at open/closed ratio, whether they use an autoclose bot, etc).
Since I can't see a world where the VC dollars stop flowing, I don't know if we'll ever be at a point where building things professionally (like... in the engineering sense) will ever become mainstream. Even if you waste 90% of a developer's salary, if that developer contributes something that increases revenue by 1%, you usually gain WAY MORE than the developer was worth as the business owner (in perpetuity as well, all other things equal). It's just not cost-effective to engineer well upfront sometimes (see RethinkDB and MongoDB), though I still strive for that.