What NOT to do when you're trying to help a newbie?

Question

^{Now that the 4th prof. van Duck's article is in press; it's time to think to the next one.}

Barbara Beeton suggested to me to read this article: https://latex-ninja.com/2019/02/26/guest-post-confessions-of-a-latex-noob/ and I've found it quite interesting.

It talks about the difficulties tackled by a newbie when s/he's asking for help, especially if s/he is not a mathematician or a computer scientist, but a humanities scholar.

I'm not talking about the difficulties in learning (La)TeX itself, but the ones to deal with when you're asking for help.

I agree with many of the things reported by the author, in particular, when she says that the experts criticize the (perfectly working) newbie's code only because it is not elegant, or when they use terms/acronyms a beginner could not know.

And I give her +1 for:

Have you ever tried to get a nice document done with Word, including lots of pictures? Yes, there is a good chance you will kill yourself trying.

My question is: which are the behaviors to be avoided when helping people, especially if they do not know anything about programming?

Edit: the answers given till now (thanks to who answered) are referring to TeX.SE. I would like also some general advice. For example, if a colleague from the humanities department ask you for help, what should you avoid doing?

Moreover, as AndrewT pointed out, we already have a Code of Conduct who tells to be friendly, etc. I would like something more practical, like the two examples I wrote above.

^{Your replies will be used by Herr Professor Paulinho van Duck in 5th article on the TUGBoat. He reserves the right to not include an answer because of moral scruples.}

Answer 1

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 ...

Answer 2

Do not confuse a newcomer with a previous newcomer. That is, try to disentangle users. Even if you are disappointed by the behavior of some newcomer, the next newcomer is a person who (most likely) does not know what happened previously and deserves to be treated with respect.

Answer 3

Asking for an MWE can be confusing to a newbie, even citing the items that explain it.

Often there is some code provided, but not a \documentclass. Since document classes behave in radically different ways, an explicit request to identify the document class is not as aggressive. In addition, ask that the OP's example be compilable and produce the problem as described, so that potential helpers can have something to experiment with.

All this, of course, is in the "canned" MWE descriptions. But those can be overwhelming. A few, politely expressed, specifics could be acted on more easily.

I'm often tempted to add that my crystal ball is inoperative, but suspect that might be taken as an insult.

Answer 4

I have several comments on what is helpful from my perspective.

• There is no standard reader. Try to provide an answer that will be intelligible to the less experienced while still helpful to the more experienced.

• Understand that a MWE is not always easy: sometime removing "extraneous" code changes the behavior that you're trying to diagnose. It's bad enough for someone with decades of software experience; for a complete noobie it can be ghastly.

• Don't just edit the code; explain what you changed and why.

• If you give a man a fish you feed him for a day; if you teach him how to fish you feed him for life. Try to explain how to diagnose similar problems in the future.

• When your answer refers to arcane or fragile concepts, give the user enough information to understand what you're talking about and to understand potential risks.

• If you close it as a duplicate, provide a link to the original question. No, an obvious search won't always find it.

• If your answer is RYFM, give the user a link to TFM.Either way, keep in mind that the user may have already RTFM and the information wasn't there, or wasn't there in an obvious location.

• If you downmark a question or answer, explain why.

Answer 5

never Forget that for some newbies there may even be a Problem in grasping what the Problem actually is. most non-cs-people / non-math-People may only see "Output not Looks like i wanted --> this is error of machine --> ask on se" therefor never expect the noob to be able to even discribe the Problem after all. also it is quite tricky to tag a Question appropriately especially if s/he is not familiar with the tags existing (which is not difficult at all, because there is a metric ton of tags already).

Answer 6

Being aware that posting a question is difficult in itself:

• You must have understood how stackexchange handles question editing.
• You have to know how to use the buttons,
• how to format the text,
• how to work markdown,
• how to attach an image,

which is not self-evident.

Translated with www.DeepL.com/Translator

Answer 7

Do not try to improve or optimize the code first.

This has several disadvantages:

• if the newbie had known how to code otherwise, he certainly would have done it by now. By modifying the newbie's code, we pose a second problem: understanding the improvements in the code. This is often not at all obvious: who has never read

I didn't understand the solution to this question, so I ask the question again.

• This suggests that the code can be optimized as if it were a beautiful mathematical demonstration. The shorter it is, the more elegant it is! What is true in mathematics is no longer true in computer science. When we write text code, it is compiled, so it is transformed by the compiler into a token. We have no control over this step at all. The compilation time, the material resources used during compilation and the result produced have no causal relationship with the length or optimization of the code.

• Code optimization must be given in addition to the answer. An addition that illustrates the weaknesses of the question's code and shows the interest and that there is a need to write this code differently. We optimize a code for a specific purpose, not to please ourselves (even if it is true that we please ourselves).

Translated with www.DeepL.com/Translator

Answer 8

Do not start hostilities by immediately pretending that the question is duplicated. But to do as moewe asked me if I agreed with him on this fact, and I quote....

The question is probably a duplicate of tex.stackexchange.com/q/31547/35864 then. Would you agree?

Translated with www.DeepL.com/Translator

Answer 9

dont try to overimprove their answer if not absolutely neccessary.

this is probably a waste of time and also can lead to code the OP does not entirely grasp.

few improvements are ok if totally obvious (with even the least latex skills imaginable) or well explained or commented.

so just focus on what was asked no matter how extremely ugly the solution by the OP is and how tempted one is to do exactly that.

in addition keep answers as short as possible because no one wants to read whole novels worth of text if not un-bypassable.