I love helping people out with technical challenges. I don’t always have as much time as I would like to dive into the details of their code though. Occasionally I get requests for help that are completely unactionable on my part. A while back Eric S. Raymond wrote a great guide on How to Ask Questions the Smart Way. If you haven’t read it I recommend it. I’ll summarize some of my tips here, which may or may not agree with his write-up. Hopefully, these will be useful as you ask for help elsewhere. These are the steps I use when I ask others for help, or post on Stack Overflow.
One note, this isn’t intended to be taken as a complaint or rant. Just some useful tips to expedite the process of asking for help.
- What are you trying to do? – Just saying “This doesn’t work” is not enough information. Let me know what you are trying to accomplish. Also, if you can tell me some context and why, then I might be able to suggest an alternative method to accomplish the objective – you may be trying to do something the hard way. A while back a friend of mine asked me of the DOS Interrupt to reverse the scroll direction of text. I didn’t know, so he spent a few more hours researching it. When he was done he showed me the assembly routine he wrote to delete a line of text and then move the text bellow it up to take it’s place. Once I knew what he was trying to accomplish I could tell him there was already a routine in the CRT unit that did exactly that.
- What have you tried? – What debugging steps have you taken? Did you set a breakpoint? Did you try it on a different device? Did you consult the documentation? Did you consult the platform APIs? Did you reboot the device? Did you read what the error message said and try adjusting your code appropriately? Depending on what you are doing, there are different troubleshooting steps you should be taking. If you can tell me what you have done, and what the results were then that saves me from asking you if you “tried turning it off and back on again?” I’ve forgotten that simple step many times, and it is amazing how often it fixes the problems. If you haven’t tried anything else yet, do that first. Not only does this save me time, but it saves you time. If the first 5 things I suggest are things you already did then I’m not helping you yet.
- Include a link to related documentation – Believe it or not, I don’t have every API memorized. To save me from doing some Googling, include some links to the pages you consulted in your troubleshooting. If you don’t have any links, then either you need to do some searching, or you need to let me know there is no documentation for what you are working on. Also, this may explain better what you are trying to do, and where you are getting your information. If you are reading an outdated document then that may be the problem, but if I don’t know where you are getting your information then I probably won’t know to suggest that. Also, by showing me the resources you’ve already tried then I won’t waste your time by sending you those links.
Try searching Google, Stack Overflow, Forums, etc. first – Occasionally it is nice to get the question that I can answer just by pasting it into Google and replying with the first link. Makes me look smarter than I really am, but after a while it gets old. Often times I’ve found that after I search for something and don’t find any results, I’ll compose my question to a real person differently than my original search terms. I then take that question and paste it back into Google and the answer appears.- Be Specific and Relevant – For example, if you are having some issues calling the Facebook API from a FireMonkey mobile application, it is useful to know you are only seeing the issue from your rooted Android tablet, using XE5, running the beta of Android “L”. On the other hand, I probably don’t need to know the color of your device’s case or your Facebook password.
- Send the Minimum Code Necessary – Please don’t paste in your entire project source code, including forms, into an email. Pasting too much code just results in an unwieldy long email message or blog comment that I need to scroll through to find the pertinent information. Usually, if you can’t reduce it down to a few lines, then you don’t fully understand the issue yet (notice I said “usually” as some issues require more code). I generally recommend trying to recreate the issue in the smallest possible sample program (sometimes called a “spike”) before asking for help. This is also a good troubleshooting step as isolating things helps to debug them (and may be a sign your code is too tightly coupled.) You can include a link to download this sample project, or attach it if that is supported (just don’t include the binaries, unless that is necessary). If that isn’t possible, then explain why in your message. Now when asking on other forums, etc. observe the tradition there. If you are submitting a bug report then a test case is a good place to start.
- Avoid Personal Attacks – I used to work with a guy that whenever dealing with someone else’s code, software, library, tool, etc. would say “If I wrote code like that I’d lose my job.” One time I pointed out it was his code. He didn’t learn. It is never necessary to insult someone, even if you believe you’ve found a bug. I’d wager that any programmer who has not written any bugs has not written enough code. Even if you are not attacking me, I don’t like working with people who feel it necessary to belittle others (and I always think the code I wrote yesterday is terrible.)
Do some legwork yourself – This one is kind of hard to explain, but on sites like Stack Overflow they call them “homework questions.” Sometimes someone ask a question that sounds like it was part of their homework. The corollary is if you are asking a question like “What happens if I try to reference an object after I free it?” Or even more complex questions, but where the answer is obtained by simply doing what you ask and observing the outcome. I might know the answer off the top of my head, but often times I would need to do the same level of work you would to test it. Now if you are curious if “X works on Y” where you don’t have access to Y, then let me know in your question. Likewise, if you did test something, and are getting inconsistent results and what a better understanding, explain that as well.- Explain it to a Teddy Bear – The Teddy Bear P
rinciple is where you try to explain the problem out-loud to a Teddy Bear, as if you are trying to get an answer. It is amazing how often just going through the process you will answer your own question, or maybe realize your question doesn’t make any sense. If you don’t have a Teddy Bear you can use your dog, child, spouse, statue of Blaise Pascal, picture of Niklaus Wirth, shrine to Charles Babbage, etc. You can take it to the next step by imagining what answers, questions or challenges might be offered to your question. It is OK to have a full on conversation with an inanimate object.
Personally I’ve found that frequently when I prepare a proper question I find the answer before I need to ask it. Especially if I try to create a test case. That won’t always be the case though, and that is fine.
What tips do you have for getting better answers? What do you do before asking for help?