Helping people effectively and to their satisfaction is an art and there are a great many aspects that come into play. I'll just list a few things here that come to my mind and that I picked up when I read the linked article.
People want to be taken seriously
I should probably not write 'people' in all generality here, but it is shorter and for that first point 'people' as in 'all people' is probably not too far from the truth. If you disagree, read this as some or most people.
Especially if people feel uneasy about asking in the first place, feeling that their questions are not taken seriously or that they are belittled can make the entire experience much more unpleasant. What exactly people see as belittling, patronising and insulting of course varies wildly.
- Some people might see it as patronising if you explain things to them that they already know. Some may only have an issue with that situation if you (should) know that they already know.
- Some people may find it belittling if you inquire about or (seem to) question the motivation behind a question or their goal (as in "Why do you want to do X?").
People want information they can understand
This one is obvious: When I ask a question, I hope for an answer that explains things to me in a way that I can process without having to look up tons of other stuff on the way. If I ask a "how do I do X?" question, ideally I want an actionable response ("take this code and put it here", here is an example that shows it in action). In particular unnecessary jargon is to be avoided, necessary jargon should be explained etc. etc. It goes without saying that I'm looking for something that works for my situation and not for a hypothetically simplified (or more complicated) situation.
I don't want to get complicated, overly long solutions that I'm never going to understand, nor page-long essays explaining the solutions to me on a level that I don't grasp. I certainly don't want to feel that a person answering my question is just showing off and does not really try to address my question in a understandable manner.
These two points already have the potential to cause conflicts: Underexplaining is clearly bad and overexplaining can also be seen as problematic. Knowledge about the background can be very beneficial for useful answers, inquiries that come across as overly critical of the background can be counterproductive.
Modes of communication
A great many issues can be avoided in personal face-to-face communication. Tone and other non-verbal cues can help avoid misunderstandings. A back and forth of clarifications and questions helps settle things much quicker.
On websites like this communication is less direct, even asynchronous at times. Besides the restriction to text-based communication without non-verbal components, there are other constraints like character limits in comments. That makes for a much different conversation.
In the comments on this site I cram in much more stuff at once than I would when talking to people directly or in real-time (chat-like). That can feel overwhelming and very demanding ('Did you do X? What about Y? Try Z.'). On the other hand that method helps to save time and inevitable breaks in the conversation may not be as abrupt and still leave some paths open for further research.
TeX.SX and its rules
For TeX.SX in particular the rules and workings of Stack Exchange and the customs of this place can be intimidating and cause frustration. See also user0's answer. In the grand scheme of things most of these probably have their use, but not in all cases and not for all people.
Apparently some people feel offended when it is suggested that their question might be a duplicate. See AndréC's first point. I firmly believe that the general concept of duplication in itself is a very useful and integral part of the workings of this site and in no way hostile nor should it be seen as such. Furthermore, I believe that (at least in general) there should not even be the suggestion that people just didn't look hard enough to find it. There are thousands of questions on this site and the nomenclature and notation in the LaTeX and typesetting world is not something everyone is familiar with. For me it becomes much easier to find duplicates once I know the solution or if I answered a similar question before and thus know some useful keywords. Duplicate questions have value: They serve as an entry point to the question they have been marked as a duplicate to. Especially if they add new search terms, they are extremely useful. But of course it is not a nice experience to have a question closed, so a healthy amount of kindness during the process won't go amiss. I think that it can help to add a few explanatory words instead of just a link or the system-generated message. If the question is still in its early stages it is also a nice gesture to ask for confirmation before you cast the initial duplicate vote.
Improving people's code
This is one point where I have to disagree with the sentiments in the linked post (https://latex-ninja.com/2019/02/26/guest-post-confessions-of-a-latex-noob/, specifically the points under fear of doing things wrong).
When I answer questions on this site and I have the time I will 'improve' the code I post in the answer. My chief argument for this is that this site is public and answers are intended to help not only the OP, but also other people with a similar issue. Avoiding common pitfalls, issue or outright errors is a service to those who browse this site in search for working solutions. The answers are intended for others to copy and so it makes sense to write the code in a way that the answerer believes is best for use by other people as well.
There are of course several levels here.
- There are things that are errors or have a high probability of causing errors in slightly different circumstances. (LaTeX is quite forgiving in some respects. Things that 'should be errors' might not cause an error, because something unexpected saves the day.) Common things are the loading order of packages or multiple package calls that might work in a particular example, but could fall apart in other situations. I firmly believe that it is in the best interest of everybody involved to solve those issues, even if they might not cause an error at this time. I think it would be negligent knowingly not to point out problems just to avoid stepping on the asker's toes. I know you only came here to get your car horn fixed, but if I see that your driver door does not shut properly and thieves could exploit that and steal your car, should I not tell you about that?
- There are things that have known issues with other common idioms or have the potential to cause problems, even in those cases I would see it as a service to exchange them for something more robust (of course with a short comment, if possible). The same holds for deprecated, outdated or superseded code.
- On occasions I will even modify the indentation. Most of my answers are about bibliographies with
biblatex and some questions already contain a lot of modifications to begin with. In some cases it is crucial that I understand what the existing code does before I can even start suggesting an answer. If the formatting of the code is too compact for me to wrap my head around what is happening, I will re-indent it in order to be able to work on an answer more efficiently. I will then retain my style in the answer afterwards (what if I need to edit the answer or want to re-use it?). I am (now) aware that some people might see this as a low-key insult towards their coding style, but on balance I think it is not totally unreasonable to stick to my approach.
Some people also don't appreciate comments on code that is not directly related to the issue at hand. Since this is a public forum and people might get inspired by posts here, I firmly believe that comments pointing out issues have their merit even if the mere fact that issues were pointed out might upset the author of the code. Of course it is important to phrase such comments neutrally and not destructively, it helps to give a concrete example why the approach has issues. In my experience people are very happy to learn about better alternatives with fewer issues.
There are several interests to weigh against each other here. People want simple and short answers; additional changes to the code require additional cognitive load to understand. People may not want to be reminded of the fact that their code might have issues. Other people may want to know about potential issues in their code that could become fatal only a few days before an important deadline. Future visitors may want to use answers (or even questions) as starting point and hope that the code works properly.
Much of the art of helping successfully is in balancing the different interests and points mentioned here and elsewhere against each other. That might get easier if you know more about the person you are helping and their history. On the internet with new users that is always a gamble, which brings us back nicely to marmot's answer. It helps to tread lightly, but you can never know what exactly someone will find unacceptable and off-putting and what is still OK.
Initially I had planned to write something about underwear as well, but not now ...