Timeline for How can you achieve and maintain flow while pair programming?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 17, 2016 at 12:12 | comment | added | try-catch-finally | Downvote (revocation possible): you don't give details on your negative experiences. Further your pro-example is very narrow. It probably affects only 10% of the developers. | |
| Dec 24, 2014 at 9:39 | comment | added | Lev | Obviously there is no guarantee, but it can help. | |
| Dec 21, 2014 at 13:38 | comment | added | Giorgio | @Lev: "If you had pair programmed, your partner would have noticed the bug and saved the debugging time.": There is no guarantee that a bug is noticed either with pair programming or with code reviews. E.g., after six hours of pair programming one might be so tired that one easily overlooks bugs. | |
| Dec 21, 2014 at 11:35 | comment | added | Lev | @Giorgio Not quite. For example, it can so happen that you make a bug, then waste time catching it, and only then get your code reviewed and commit. If you had pair programmed, your partner would have noticed the bug and saved the debugging time. | |
| Dec 18, 2014 at 12:06 | comment | added | Giorgio | @Lev: Having a code review before committing is much more efficient: the review takes from a few minutes to half and hour, instead of an entire workday. | |
| Apr 2, 2013 at 10:03 | comment | added | Lev | The point of pair programming is not stopping each other from slacking off; that wouldn't even be effective. The point is having code review in real time. | |
| Nov 18, 2011 at 20:03 | history | answered | Jim In Texas | CC BY-SA 3.0 |