Is there any system we can use if we don't yet have that intuition?
Sure. We can share and reverse-engineer a bit of our intuition to create a system. A bunch of rules-of-thumb, so to speak.
The following will be my opinion and I encourage others to create a post of their own. In the end, you'll have to decide for yourself what YOU think you should be doing, within the rules and within reason, of-course.
Don't post 2 questions on the same day unless they are quite related.
- For example, you have a project consisting of a core, extension scripts and a database handler. Marking them as parts of a project and posting them all on the same day with cross-links to one another is not unheard of. For iterative reviews though, this does not apply.
- Keeping the above in mind, it's usually preferred to wait anyway. Mistakes you made in one piece of code are likely to be apparent in a second as well, especially if they are all written in the same language.
It can take a couple of days to get an answer. One answer may not be the only one you receive. To get the most out of a question, wait a couple (2) days at least before accepting an answer. Take the answers to heart and make sure you've fixed at least those problems (or describe why you think they should not apply to your code) before posting a new question. So, a minimum of waiting 3 days between questions seems appropriate, adding days the longer it took to receive an answer.
However, as you said, it's not about absolute time.
Also, the question and most of the answers seem to be mostly focused on a total number of questions, and use of feedback throughout the chain, rather than frequency.
Don't post the same project 8 times in one month. Code Review, like any site in the Stack Exchange network, consists of volunteers and it's bad practice to abuse someone's generosity.
This is what an iteration could look like:
- Write code which works as intended.
- Clean it up.
- Have it reviewed for those things you missed.
- Clean it up.
- Ask yourself: do I want this code to be even better? Did I change enough to warrant a new review?
- If yes,
goto 3..
Say you had performance issues. The first iteration took care of those and some maintainability problems you had got take care of in the second. Do you need a third? Perhaps. Let's say the third review only shows you forgot some minor things and you changed those. Does this warrant a fourth round? Probably not.
The thing about iterative reviews is it's a track that will eventually boil down to 'this code looks fine'. If you listen to the advice given in answers, that point will eventually come and you can stop asking questions about that specific project. If you ignore the advice in the answers, eventually answers will stop coming. Whatever you do, don't post the exact same code twice. That's called a duplicate and the second question will be closed as such.
