> The end user, the one who pays the majority of our bills, doesn't give a shit about your language choice, your code, your DB choice, or any of it. They care i

> The end user, the one who pays the majority of our bills, doesn't give a shit about your language choice, your code, your DB choice, or any of it. They care if it works, if it's easy to use, and usually if it looks nice and that's about it. The problem is that this doesn't mean every option is equally good for the end user. A lot of software that gets belittled is criticized for being a good way to provide a bad product. These are tools that are great for getting things done quickly and smoothly, in return for kicking the can down the road on reliability, security, or modifiability. Think of the small insurance companies which offer easy signup at low rates - and then don't come through when you file a claim. When people go out and produce lengthy essays on why Mongo is dangerous, it's often a response to seeing systems that work for now, but are likely to fall over completely sometime after the contract is done. When your database offers high throughput by not actually checking for successful writes, it's easy to hand over a performant system that's going to lose a bunch of medical records the first time a server fails. So no, the client doesn't know or care, but all too often that's because they're getting immediate benefit in return for delayed, probabilistic risk, and no one is telling them about the tradeoff. None of that is justification for being a jerk, or mocking actual people (obviously!) Nor is it a reason to pretend that Mongo is never a good database choice, or that PHP is never a good language choice. And you're right about the grossness of mocking beginning programmers for starting with approachable tools. But I object to the idea that the value of debates should be measured by whether users care about them. I'm not much interested in what my bridges are made of, but that's because I have faith that someone behind the scenes built them reliably. All too often, that's not the case in software.