13
\$\begingroup\$

In my search for the gory details of the Dos and Don'ts of iterative reviews, I saw that we should always ask another question with our follow-up. However, I haven't found anything about how long we should wait. Elsewhere, I've seen that we should wait a day or two before choosing a Best Answer, so I wondered if we should wait until after that. However, while trying to figure out what's normal, I've also seen iterative reviews be posted in the same day. Is there a preferred waiting time to requesting an iterative review? I found this faq question, but it didn't mention anything about timing either.

In this question, there's a lot of discussion about posting "too much", which is what I was afraid of doing for many of the same reasons. However, I'm struggling to figure out what would specifically tip the scales. Janos gives an excellent answer with various reasons of why posting too much is bad, but he seems to be drawing on his intuition he built over years of being highly active. Is there any system we can use if we don't yet have that intuition? 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.

\$\endgroup\$
  • 3
    \$\begingroup\$ Does this question and its answers help? Is code ever clean enough? - Can there be too many follow-up questions? \$\endgroup\$ – Simon Forsberg Nov 2 '17 at 21:02
  • 1
    \$\begingroup\$ It does help in a way. I had looked at that too before posting, but it was also part of my confusion :) I should've linked it. It seems like there is an intuition only frequent reviewers have about these things, and I was hoping to glean insight. Janos and several others talk about posting "too often", and then give reasons why it's bad. One person says it's impossible to have a solid number, but reasoning elsewhere would seem to generate an answer given enough info about the site mechanics, which I don't have. I'll edit my question to elaborate. :) \$\endgroup\$ – BrainFRZ Nov 2 '17 at 21:53
  • \$\begingroup\$ @SimonForsberg I've updated my question with the link and some more clarification of my question. Thanks for having me go back to it! \$\endgroup\$ – BrainFRZ Nov 2 '17 at 22:03
11
\$\begingroup\$

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.

  1. 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.
  2. 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:

  1. Write code which works as intended.
  2. Clean it up.
  3. Have it reviewed for those things you missed.
  4. Clean it up.
  5. Ask yourself: do I want this code to be even better? Did I change enough to warrant a new review?
  6. 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.

\$\endgroup\$
  • 4
    \$\begingroup\$ If there's anything I can do to improve this answer to suit your question more, please comment. We've had questions like yours before and it would be great to have answers helping new users like you along in this regard. \$\endgroup\$ – Mast Nov 3 '17 at 10:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .