#After you ask your question
So you have asked a question, how do you ensure it succeeds?
###Keep in touch!
Many times reviewers will have additional questions for you in order to understand and clarify your code (or context). You should understand that you wrote the code so understanding it is easy. Reviewers have a disadvantage here, and will need help. Use these types of questions as a learning opportunity to understand how other people 'think' and how it should change the way you describe your programs in future. It is a very valuable skill to be able to describe your problems and solutions in a way other people understand the first time. Use this as a way to learn that skill, and to learn what sorts of things in your code and description are hard to 'grok'. Do not be offended that other people can't see what is 'obvious' to you.
Additionally, a person who engages positively with the reviewers is likely to get a more personal and well-thought-out answer.
- Be available to answer questions, and be respectful no matter how stupid you may think the question is.
###Swallow your pride
It is inevitable that people will find faults in your code, thinking, or style. You will be criticized, and mistakes will be pointed out. This is a good thing. This is an opportunity for you to learn, and it is why you are here. Read all the answers, and comments, and understand them. Sometimes answers point out things that you disagree with. This is OK. The trick is to understand that there are multiple ways to do things, and what may work for someone else, may not work for you. Still, you should understand why this will not work for you, and accept that the advice given does not apply in your context.
There is no value in getting defensive or upset about the criticism. Rather, even if you feel defensive or upset, it is OK, and you can either dismiss the critical opinions entirely, or use them as a way to learn about yourself, your code, and your peers. Do not engage the person though in a dialog, or try to 'educate' them as to why what you are doing is right, and why their answer is wrong. Despite what you may think, this does not actually work out well. The truth is that the other person has no emotional involvement with your code, so they will not feel things the same way you do. This is human nature. Get over it, it happens.
- Criticism can be hard to take. Do not take it personally, and use it as an opportunity to learn. Not all criticism is right either, so it is OK to disagree, but do so respectfully
###Vote and Comment
The best way to 'say thanks' is to up-vote on answers that help you, and to accept the answer that best addresses what you think was important in your question.
If an answer is not helpful at all, then down-vote it.
There will often be multiple good answers, and you can only accept one. This is a known flaw in the Stack Exchange system for the Code Review site. We know that, and as a result, we also know that not everyone can have an accepted answer even if we all have good answers. You should not feel 'guilty' about accepting one answer and not accepting another. Up-vote all the helpful answers, and accept one if you feel it helped you the most.
- Votes are good for everyone and are a feedback mechanism too
###Follow up
If you got answers to your question that helped you, and you want to make changes to your question, and re-ask it with a different focus, then the right thing to do is to post a new question with the revised code.
This is a good thing. It shows how you are progressing, it allows you to focus the question in to things that were not reviewed the first time, and it gives everyone another opportunity to ask, answer, vote, and earn those mysterious internet points.
If you have used advice from a previous question to improve your code, and that improvement represents a substantial change to the code (warranting a new code review) you should consider posting the follow-on. Be aware that substantially similar code posted for re-review could leave reviewers wondering, "why is this being posted again?" On the other hand, most reviewers find it gratifying to see that their time spent reviewing the original code resulted in you being able to really improve your code.
- If you engage personally with reviewers you will likely get a more personal response
