#Queue Requirements
Queuing is a wonderful tool for asking and receiving help. But part of WDI is learning how to help yourself--learning how to identify errors and potential bugs, learning how to explore problems, and learning how to find a solution--and queueing for help shouldn't hinder that development. If you queue up, it is expected that you have already tried to go through the bug solving process.
Below is a list of prerequisites for queueing. If you skip one before queueing (especially the first one), your turn for help will be skipped, and you must start again at the bottom of the queue after completing all missing steps.
##Check Indentation Your code must be properly indented. Period.
##Read and Understand the Error Message If part of your problem involves an error message, you should be able to explain it to the TA in detail. If you have not checked the line and the file logged in the error message, you will not receive help. If you have read it but do not understand it, research it.
##Read the Documentation Sometimes things work in unexpected ways. Sometimes we just don't get how things work (but think we do). And sometimes we bravely use something that we have no idea how to use. In any of those situations and more, it's worth checking the documentation for whatever language, gem, framework, library, or whatever else you are using. Often it will clarify how to properly use a method or supply example use cases.
##Consult Your Neighbors Always take a moment to check if those around you encountered the problem or have ideas on how to approach it. There are a few ways in which this can bring about a solution:
###Explain The Problem In programming it is very common to overlook a minor issue. Programmers usually make the mistake of skimming their code in search of an error instead of taking the time to read it thoroughly. By explaining the problem to someone else you force yourself to read the code one step at a time, and possibly catch any mistakes in the process.
###Have Someone Read Your Code Similar to the suggestion above, sometimes all it takes is a fresh pair of eyes to glance at your code and notice a typo. Don't be ashamed of asking your neighbor to quickly read a segment of code and see if anything is amiss.
##Explore the Code (Binding.pry)
Sometimes, when no tools, methods or technologies are able to diagnose a patient’s ailment, doctors (okay, nowadays mostly veterinarians) will just cut them up and look at what’s happening inside. Coding is no different. If an error message doesn’t specify a line number for any reason, or if your code is behaving in a weird and unpredictable way, put a binding.pry where you THINK things are going awry (and if you aren’t sure, guess!).
##Google It If you are having a problem, there is a 99.99% chance that someone else has already experienced the same issue and found a solution. Always try to google the situation, and be sure to include any relevant keywords such as 'ruby' or 'map'. Have you discovered Stack Overflow yet?
##Have a Cookie Ready No oatmeal raisin, please. Note: This one is optional