You see this phenomenon here on HN all the time. Find anybody asking a question or help to figure something out and the first couple answers will likely be "why are you doing it that way?", followed by almost completely useless advice to do something else entirely a completely different way.
Well, it is often useful to ask why a user wants to do something a particular way, and commendable to inform them if it’s bad practice.
The trouble is, if you’re going to reply that way, you should strive to first answer the question, as asked. If the answer is bad practice, of course, you should mention that.
That’s the respectful way to handle a misguided question, in my opinion. Give the reader both solutions, explain why the alternate is better, and leave it to the reader how to proceed from there.
The one case where I think it makes sense to say "Don't do that" unequivocally is with security issues. Cryptography SE gets a decent number of people asking some variant of "how do I implement <incredibly insecure harebrained scheme>" to which the only correct answer is "Don't do that. It's unsafe."
The really funny thing is that the OP of that question ignored absolutely everything being suggested, finished the project himself, and then posted an answer saying as much on his own question (yeah, an actual answer as opposed to adding an "edit" to his OP!), never selected a best answer, and then mods closed the post. So now any DIY'er who encounters the same thing OR even worse encounters something different but still thinks it's the same thing will believe it's perfectly safe to roll the dice and continue the project on their own, likely killing themselves and/or loved ones. I don't have sympathy for them, but I sure do for their families.
I've been doing this stuff a long time, there's usually a reason why I'm doing it the way I'm doing it. I understand you don't like it, think it shouldn't be done that way, and so forth.
But I promise you, I've already considered the alternatives. And if you mention an alternative I haven't considered, I'll consider it then.
But please, for the love of god, just answer the effing question and stop assuming you know the nuances of my problem better than I do.
> I've been doing this stuff a long time, there's usually a reason why I'm doing it the way I'm doing it.
People who've been doing it long enough probably also have the experience to know how to ask a good question that explains the why of the unusual request.
"I unfortunately stuck on an low-power embedded device that for some weird reason only supports MD5" is going to be treated differently on SO than "I'm new to PHP and I'm using MD5 for to encrypt passwords but I can't reverse the encryption to read the password!"
at which point you get into arguments about whether or not you really should be taking that approach.
just answer the damned question, and if you have concerns, ask. I'm more than happy to explain it, I just don't want to have an hours long discussion when I asked a fairly specific question.
This behaviour is particularly bad on a Q&A site that aims, as SO claims to do, to optimise for future readers (rather than the individual asking the question).
It leads to a page with a clear question at the top and a great deal of text below which is not an answer to that question.
> Why you're doing something is part of the conversation and its context.
...and is often a way to shift the conversation to an argument about why the asker is doing it that way instead of giving them the information they actually asked for. I don't have time to argue about the sequence of events and layers of requirements that led to me asking the question, it doesn't matter if this "isn't the right way" to do it, it's the way I need to do it.
That is a poor example. Rust and Python are vastly dissimilar, and one could easily be recommended over the other for various reasons. Python for portability, Rust for system oriented programming. To say you don't use rust because you don't know it is an excuse, and a terrible one at that. i would say the learning curve of Python is similar to Rust, why not learn?
