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.

  • Do you mean something else that are not yet listed on the Code of Conduct? – Andrew T. Mar 1 at 8:13
  • @AndrewT. Yes, like the examples I cited. – CarLaTeX Mar 1 at 8:24
  • 3
    I would really like to understand how this question received a downvote. – marmot Mar 3 at 17:40
  • @marmot Downvoting is often strange :) – CarLaTeX Mar 3 at 17:43
  • 1
    Yes, but I am a very curious marmot (and luckily not a cat!), and would like to also understand strange things. ;-) – marmot Mar 3 at 17:44
  • @marmot me too! – CarLaTeX Mar 3 at 17:46
  • 1
    What you should not do? You should not expect gratitude or even appreciation, either by the O.P. or by others... – user31729 Mar 10 at 15:33
  • 1
    @ChristianHupfer Do not do good if you cannot stand ingratitude (cit.) – CarLaTeX Mar 10 at 16:14
  • 1
    @CarLaTeX: Nope, it goes the other way round: 'If you can not express gratitude, you should not expect help' -- Source: Christian Hupfer ;-) – user31729 Mar 10 at 17:09
  • @ChristianHupfer Interesting point of view, but it's not true here on TeX.SE :) – CarLaTeX Mar 10 at 17:39

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

  • +1, best answer till now – CarLaTeX Mar 2 at 11:56
  • Do you find that the way these questions was closed as duplicated is not hostile? tex.stackexchange.com/q/477264/138900 and this tex.stackexchange.com/q/477263/138900 ant this one tex.stackexchange.com/q/477212/138900 – AndréC Mar 2 at 12:49
  • @AndréC I admit that those examples are tricky. I am talking, however, about the general concept of duplication and want to emphasise that duplication in itself is not already a hostile act. It may well be that particular instances of duplication can be seen as negative towards users especially if accompanied by strongly worded comments or if the suggested duplicate is not that close to the original question. – moewe Mar 2 at 13:16
  • @AndréC I edited the answer to put emphasis on the general idea. Most of my points are general and with a bit of effort you can probably find particular instances that would constitute counter examples to some (or better all) of my claims. As you can imagine this part of my answer is more or less a response to the first point in your answer, which I interpreted (broadly) as saying that suggesting a duplicate (you say pretend it is, which for me carries the implication that it might not be a duplicate, but you don't make that explicit) is hostile. I disagree with that. ... – moewe Mar 2 at 13:24
  • 5
    ... For sure, there are hostile ways to suggest duplicates. But the idea of duplicates is not hostile (or at least it should not be). And there are perfectly neutral and non-hostile ways to suggest duplicates. – moewe Mar 2 at 13:26
  • The way you say changes everything and that's why I gave as an example your way of saying that there is duplication because it requires the approval of the person asking a question. Associating the PO with the closure of the question makes it possible to operate the site in an intelligent way. I hope that your approach will become more widespread. – AndréC Mar 2 at 15:22
  • 1
    Totally agreeing on the reformatting part. I do this most of the time. Especially in tables. The way people enter tables seems way too counterintuitive for me to read them at code level. But also macros and stuff often isn't indented to my liking and I tend to redo those so that I can skim through the code faster in the future. – Skillmon Mar 9 at 8:54

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.

  • 2
    Mr. Marmot should receive a Trophy from Tex.SX. – Lin Mar 7 at 3:50

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.

  • 3
    +1 for the sentence with the Crystal ball. LMAO. i personally would take that with humor but there is only one way to find out if its insultiv or not... – der bender Mar 1 at 16:25
  • 7
    @derbender -- I actually do have a crystal ball, a very beautiful one of rutilated quartz. It's admirable as an ornament, but quite deficient in terms of providing useful information. Anyhow, thanks for seeing the humor in the suggestion. – barbara beeton Mar 1 at 18:19
  • well it just sounded too stereotypic and too odd to assume the ball's existence in the context given. – der bender Mar 2 at 18:05
  • 1
    How about this crystal ball? ;-) – marmot Mar 2 at 20:04
  • @marmot -- That's a lovely crystal ball, but I thought it had been stolen? – barbara beeton Mar 2 at 20:47
  • Yes, precisely. Which is why we cannot use it. ;-) – marmot Mar 2 at 20:48
  • @marmot -- Indeed, there are many reasons why crystal balls aren't a practical approach. – barbara beeton Mar 2 at 20:51

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

  • One thing to make sure is that the negation does not slip through the sentence: It would be really bad to start expecting that newbies are not able to describe the problem properly. – moewe Mar 2 at 11:56
  • some may some not. unluckily i know quite a number of People that use the "Output not Looks like i wanted --> this is error of machine --> ask on se"-principle in some Variation or another heavily – der bender Mar 2 at 18:03
  • I guess I was just trying to be clever here for no real gain, sorry. My point is that it is OK (and maybe even a good idea) not to expect that a new user is able to describe the issue properly. But that one would be guilty of the arrogance people ascribe to 'experts' here and elsewhere if one were to expect that new users are not able to describe their issues properly. – moewe Mar 2 at 20:11

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.

  • 2
    +1, I agree with your points, except when you say to provide the link of the duplicate, when you close a question as a duplicate, it always appears the link to the duplicate automatically. I'd also add, don't use acronyms without explaining them (what RYFM and TFM mean?). – CarLaTeX Mar 5 at 5:57
  • 1
    When one suggests a duplicate the system automatically adds a comment with a link to the suggested duplicate. That comment is deleted when the question is actually closed, but then the question itself displays a prominent link to the duplicate and automatically redirects unregistered users. It would indeed by absurd to close a question as a duplicate without giving a simple route to the duplicate, but fortunately, the duplicate is always easily accessible. – moewe Mar 5 at 7:36
  • 1
    @moewe -- It hadn't actually registered for me that the comment suggesting the duplicate is deleted when the question is closed. Sometimes that comment has additional information indicating why the duplicate is suspected, and that is lost. In such a case, it would be useful to post two comments, one pointing to the duplicate, and another with the additional details. – barbara beeton Mar 5 at 14:03
  • 2
    @CarLaTeX RYFM = Read Your Fine (redacted) Manual foldoc.org/RYFM, TFM = The Fine (redacted) Manual – shmuel Mar 5 at 21:02
  • @shmuel Thanks for the explanation :) – CarLaTeX Mar 5 at 21:08
  • 1
    @CarLaTeX Someone mention RTFM: tex.meta.stackexchange.com/q/6507/1952 – Ignasi Mar 7 at 8:56
  • @Ignasi Thanks! – CarLaTeX Mar 7 at 9:12
  • Isn't RTFM=Really Terribly Fast Marmot ? ;-) – marmot Mar 7 at 21:33
  • +1 especially points 3 and 5. – Alan Munn Mar 8 at 15:22

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


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

  • 1
    What I mean is that LaTeX documents are compiled in such a way that they can be read by processors that cause machine language. We write in a high level of language. Just because the text document is short does not mean that the machine language document will be shorter and vice versa, just because a text document is long does not mean that the machine document will be longer. – AndréC Mar 1 at 10:39
  • 5
    Re 1) One important thing to teach or keep in mind is that suggesting duplicates is in no way a hostility in itself nor should it be seen as such (of course there are non-neutral ways to do that that are hostile, but that is true of so many things). It should definitely not be interpreted as a low-key insult along the lines of 'you don't know how to google, here is the answer I found with only ten keystrokes'. It is very, very unfortunate if people (new to this site or not) see it that way. ... – moewe Mar 1 at 11:05
  • 11
    ... In my time on this site I realised that it is much easier to find a duplicate if you know the answer already or have answered something similar yourself. Closing of duplicates (if they are indeed duplicates) is a fundamental part of the workings of this site: It helps keep content concentrated at one place and avoids that the same things are said over and over again with no real gain. – moewe Mar 1 at 11:07
  • 1
    Re 3) Agreed, but I think it is sufficient to leave a link to one of the established MWE tutorials. Coming up with good MWEs is an art and trying to teach it in the constraints of the comments section might just not work out. Of course it helps if can answer concrete questions about the MWE creation that the OP might have, but again I think that linking to other resources is fine. – moewe Mar 1 at 11:12
  • 3
    Re 4) This one is tricky: It is important to remember that answers on this site are intended to help not only the OP, but also a wider audience of future visitors with similar problems. It can then be extremely helpful to make sure that the code example in the answer does not contain some pitfalls, potential issues or outdated code used in the answer. This is not so much about performance or simple length-of-code-in-characters (about which you are probably right). But it is about coding practices and using good and stable interfaces: Take things such as package loading order ... – moewe Mar 1 at 11:23
  • ... involving hyperref and other packages. New users might not know about this and might not have hit the issue that comes with the 'wrong' order, but knowingly leaving the issue in just to avoid offending people would not help if you look at the overall picture. I will also modernise the code when I answer biblatex questions: Deprecated commands like \labelnamepunct can be replaced by their more powerful successors. I appreciate that some people might not want spend time thinking about using nicer or 'better' interfaces as long as everything works. – moewe Mar 1 at 11:28
  • 2
    I can even almost understand that some people may feel criticised when I 'improve' their code and that they feel that I'm trying to show off my impressive skills or much worse that I'm just trying to make them feel bad. On the other hand, some people are happy if they get additional help and code that is easier to understand and maintain. – moewe Mar 1 at 11:33
  • @moewe I really appreciate your comments. Can you give us an answer? – AndréC Mar 1 at 11:48
  • I'll think about it, though I'm not sure how much positive stuff I can contribute. Most things I wrote here were direct comments on your points and may not warrant an answer in their own right. – moewe Mar 1 at 11:58
  • @moewe LaTeX is difficult and the one who posts a question does it as he knows how. Improvements to the question code make it even more difficult to read the solution. If we want to show possible improvements, it is possible to add an addendum to the answer explaining what can be improved and why it adds value. – AndréC Mar 1 at 12:15
  • @user0 Not with LaTeX where the text code of the source file is interpreted in terms of token. The PDF output is not proportional to the length of the source file. The compilation time and memory used during compilation is not related to the length of the source file. – AndréC Mar 1 at 15:19
  • @user0 What should I change in my answer that is not clear to you? – AndréC Mar 1 at 15:51
  • @user0 I'll try, but I'm afraid I'm going to have to write too long a paragraph. I'll try to keep it as short as possible. – AndréC Mar 1 at 15:58
  • @user0 i just do it. Is it better ? – AndréC Mar 1 at 16:34
  • 1
    If I have something in my code that is a ticking time but, then I appreciate a polit explanation of why it is dangerous. I'd rather fix it now than when it blows up. – shmuel Mar 7 at 20:43

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


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.

  • Is it necessary to make two answers? Can't you combine these two answers into one? – AndréC Mar 3 at 6:23
  • @AndréC With questions like this it makes sense to split separate points into separate answers. That way people can vote on each point independently and don't have to consider the package deal. – moewe Mar 3 at 6:45
  • @moewe Well then I'll do the same with my answer: each part will make only one answer. – AndréC Mar 3 at 6:48
  • @AndréC Do as you please. I decided that for me, on balance, it made sense to keep my answer together (because I did not want to have too many answers flying around and because I wanted to have one self-contained text where one can easily refer to other bits), there are arguments to be made for both approaches. – moewe Mar 3 at 6:51
  • @moewe it's done now :-) – AndréC Mar 3 at 6:56
  • @AndréC I see. Note that you might have skewed the metric by keeping the original answer alive and giving one point a head-start of +3 votes. Note that the comments have also been partly invalidated/are attached to the wrong answer now. It would be a shame if they were just deleted as no longer needed, but maybe a moderator can move them to the correct answer? – moewe Mar 3 at 6:59
  • Yes, those who want to withdraw their vote can do so, the system allows for retraction. – AndréC Mar 3 at 7:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .