Categories
Commentary

How to Get Answers to Your Questions

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.

  1. 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.
  2. 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.
    We've tried nothing and we're all out of ideas
  3. 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.
  4. Let Me Google That For YouTry 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.
  5. 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.
  6. 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.
  7. 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.)
  8. Stack OverflowDo 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.
  9. Explain it to a Teddy Bear – The Teddy Bear PTeddy Bearrinciple 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?

11 replies on “How to Get Answers to Your Questions”

Broadly in agreement with all that, with two caveats:
1. The Teddy Bear Principle, though much cited, doesn’t really work. The ‘understand the problem by saying it’ thing only functions properly if you are actually wasting a real life colleague’s time. I believe this is because it is somehow fuelled by the kick of embarrassment that you get 0.25 seconds after realising the truth.
2. Sadly, nobody who needs this advice will ever read an article like this.

Good advice. I have bookmarked this and may use it in one of those too-common ‘please clarify’ comments on a Stack Overflow question 🙂

I frequently ask “who wrote this crap?” when reviewing my own code. And yes, I know it’s my code at the time. 🙂

I also generally agree with what you have written. Forming question corectly is the first step in getting the answer, either from others or finding it by yourself.

But the min problem is that forming correct question is someties extreemly difficult. Quite many times you will know basically what the end result would be but you won’t have a slightest idea of how to get there. And becouse of that you probably won’t be able to ask the right question.

I know this from my own personal expirience. You see I’m a self taught Objective Pascal programmer who doesen’t have any kind of education from any of the computer related technologies. Becouse of that I had quite great difficulties understanding proffesional terminology. And that can be a great obstacle of finding out the required answer by yourself.

I can’t even count how many times finding an answer for me is just figuring out the correct professional term for the job I wannaa do.
And becouse of that I’m also often reinventing the wheel quiote often by implementing some things by myself from scratch. And usually once I’m done implementing them I found code solutions for those implementations which were available all along but I just didn’t find them since I didn’t quite know what to look for.

I have this terrible picture in my mind right now of touring the Delphi development facility and encountering row after row of Romanian programmers talking to teddy bears.

An almost certain way to get the right answer, is to post a wrong one on the internet 🙂

Seriously, though: These 9 points are a must, although point #9, should probably go to the top spot.

Jim, your comments were thoughtful, but they didn’t tell how to submit our well-formulated questions.

Comments are closed.