5 ms·

I think davedx read the article, davedx even copy/pasted/quoted it, and I totally agree, the author is being overly simplistic in the analysis made. And on the

I think davedx read the article, davedx even copy/pasted/quoted it, and I totally agree, the author is being overly simplistic in the analysis made. And on the other hand, somehow the author of the article passes asynchronous code reviews as good thing. I mean, that is THE problem that pair/mob programming is solving, imho.

kstenerud 5y ago
I don't understand... what is wrong with asynchronous code reviews? From my POV code reviews are the solution to the pair programming problem.
- nijave 5y ago
  Async code reviews are slow. A code review is about getting people to agree on the code being reviewed (ideally using a set of objective guidelines). Instead of having a review done in an hour, for instance, it can easily stretch into days of back and forth to reach a consensus. Throw in a third person and now you have 3 people trying to asynchronously synchronize on a desired outcome. You could say "ok, I'll just do something else while waiting on the review" but then you introduce new problems - more context switches - the longer code goes unmerged, the more conflicts can build up - unmerged code can block other things
  - kstenerud 5y ago
    Wow... If this has been your experience then you've had rotten luck. I've never experienced this in 25 years developing professionally. On a typical code review, a reviewer takes about 10-15 minutes tops to review the code in a PR. 75% of the time the code just gets approved. Otherwise it's usually a few minor points that are 2 minute fixes, and rarely it becomes more involved because the person was unaware of something important (so a 20-30 minute fix, or perhaps a meeting to discuss the issue and come to a concensus if nobody's really sure how to deal with it). PR code chunks are kept small so that things are easy to review, and easy to switch back to if there's a problem. Generally there's 0-1 cycles per review. If we're working on something big, we make an integration branch for that feature and then merge the changes in multiple small PRs again, so that only the integration branch itself needs to be kept up to date with mainline. Blockages due to unmerged code are unheard of (at least I've never experienced it). I do on average 3-4 code reviews per day, and this has been my experience for my whole career (aside from two places that did pair programming instead) spanning many companies from startups to multinationals.

kstenerud 5y ago

I don't understand... what is wrong with asynchronous code reviews? From my POV code reviews are the solution to the pair programming problem.

nijave 5y ago
Async code reviews are slow. A code review is about getting people to agree on the code being reviewed (ideally using a set of objective guidelines). Instead of having a review done in an hour, for instance, it can easily stretch into days of back and forth to reach a consensus. Throw in a third person and now you have 3 people trying to asynchronously synchronize on a desired outcome. You could say "ok, I'll just do something else while waiting on the review" but then you introduce new problems - more context switches - the longer code goes unmerged, the more conflicts can build up - unmerged code can block other things
- kstenerud 5y ago
  Wow... If this has been your experience then you've had rotten luck. I've never experienced this in 25 years developing professionally. On a typical code review, a reviewer takes about 10-15 minutes tops to review the code in a PR. 75% of the time the code just gets approved. Otherwise it's usually a few minor points that are 2 minute fixes, and rarely it becomes more involved because the person was unaware of something important (so a 20-30 minute fix, or perhaps a meeting to discuss the issue and come to a concensus if nobody's really sure how to deal with it). PR code chunks are kept small so that things are easy to review, and easy to switch back to if there's a problem. Generally there's 0-1 cycles per review. If we're working on something big, we make an integration branch for that feature and then merge the changes in multiple small PRs again, so that only the integration branch itself needs to be kept up to date with mainline. Blockages due to unmerged code are unheard of (at least I've never experienced it). I do on average 3-4 code reviews per day, and this has been my experience for my whole career (aside from two places that did pair programming instead) spanning many companies from startups to multinationals.