When I am working on a deep programming project I tend to spend a good amount of time asking questions and also paying it forward by answering questions. I handle a lot of beginner questions and thus have found that many people have no idea how to ask for technical help or programming help at all.
First rule: You are not entitled to anything.
Second rule: Explain your overall goals (What are you trying to do)
When you are asking for technical help of any kind, you have to remember that the stranger on the other end has literally zero idea of what you are doing, how you are trying to do it, and what your desired outcome is.
Your #1 goal should to try not to be vague. So many people come in with all their technical terms about what they’re trying to do not realizing that starting off that way can be really confusing and that the way they think they’re supposed to be doing something isn’t even the “right” or best way.
Read these two statements and decide which is the easiest to help with:
“Can I get a list of all sub pages of a parent page and display them on the parent page?”
“I have a website where I need to list a educational courses and lessons. I need to be able to create an “Academy” and then create a course for each academy and a lesson for each course”
For me, and most other people, the second one is the best start for getting help. You immediately get an idea of what the person is building, what kind of content you are working with, and are led to asking more specific questions.
The fact is, this is a real life example. A user asked the first question and had I just googled it and given him whatever answer, no matter how hacky it was, he would have had it done and left relatively happy (for now). The thing is, though, that in probing for my questions I found that the better question should have been the second one that I made up and wound up directing him entirely away from parent/child pages based on his requirements.
Had I just given him the answer to his initial question he would have been back in the room at most a day later with a new more complicated problem and would have wound up ripping the whole thing apart and starting over.
Third rule: Give all relevant information
You would be amazed at how often people leave out extremely important information just because they didn’t think it was needed. If it’s at all relevant to your needs, share it. Someone debugging your code that they have never seen or working with before could possibly use it. Even if it wasn’t valuable to you when it happened.
If you did any testing on your own, make sure to tell the person helping you what you did and what the outcome was. That could minimally skip the task of asking you to test something you already did and ideally could give the person enough info to tell you what is going wrong. Do not leave out any dependancies (such as, “this needs X to work”) and any requirements (“this code must also work on an iphone”).
The biggest rule is respect. Even if it feels like the person helping you is asking mundane or weird questions, answer them. The person helping you is doing it for free, they don’t have to be doing it at all. Remember that people have different ways of debugging things and some people need to move through some of the basics before they get down to the real debugging.
Oh and one last thing:
RESPOND QUICKLY! If you can not respond to the person trying to help you quickly, don’t ask for help or tell the person you will be AFK for an extended period of time. There are few things more frustrating than 5 minutes between a question and an answer.