The frustrating thing is, how, precisely, are you supposed to teach that every bit of complexity isn't necessary, the world hasn't changed, and a few-hundred-line solution works fine?
This is an entirely serious question. I've got multiple few-hundred-line projects in development at work replacing internal tools - yes, they solve 90% of the use cases but the remaining 10% were generally either ill-advised or theoretical - and I don't know either how to get teams of developers not to build bloated messes or how to communicate that my smaller product shouldn't be taken less seriously for having fewer LOC.
I totally agree that it's a legitimate concern. I share it. From an internet comment point of view, the first thing is to steer clear of, say, the top 5 "you suck" sorts of comment. Because if you fall into one of those, or get interpreted that way, then you're not teaching anybody anything, just putting someone down and encouraging worse from others.
If you know more and have something to teach—and accidental software complexity is an extremely under-taught topic—the burden is on you to establish a context in which real communication is possible. How do you do that? I'm not sure; we could probably exchange notes on this for hours.
This is an entirely serious question. I've got multiple few-hundred-line projects in development at work replacing internal tools - yes, they solve 90% of the use cases but the remaining 10% were generally either ill-advised or theoretical - and I don't know either how to get teams of developers not to build bloated messes or how to communicate that my smaller product shouldn't be taken less seriously for having fewer LOC.