3 ms·

I never did pair-programming but I really liked the implied pair programming that resulted from having a checkin-partner that had to review and greenlight your

by kriro 12y ago

I never did pair-programming but I really liked the implied pair programming that resulted from having a checkin-partner that had to review and greenlight your commits. After sending the request you'd walk over and talk about the code for a bit. Usually pretty informally (over a coffee or water if there were a lot of commits :P). It usually went "ok tell me what your code does" and then some talk about details, design tradeofs, identified issues. Sometimes there was a rubber ducking effect of sorts where you figured out an issue with the overall code design but the major benefit was that it forced you to write code that is not too long and can be reasoned about "in a vacuum" (kind of). Second major benefit was that it forced you to physically walk away from the computer which has all kinds of benefits. All informal, nothing set in stone. We just used IM-DND to indicate that you shouldn't walk over just now because I'm in a no-disturbe mode of coding. You can probably bundle it up, write fancy DND/checkin-greenlight software and brand it as "Coffee cup driven software development". Agile and at least 4.0 ;P

gedrap 12y ago
I've done that for non-trivial commits and found it much better than someone reviewing a commit alone. When you are reviewing a commit alone, it's very easy to just skim through and not be aware of details.
rudimental 12y ago
The social aspect makes coding more fun. And getting away from your keyboard is great. What you're describing to me sounds like informal code review, a high level walkthroughs of what your code does and what choices you made and why. It's a taste of pair programming. Talking through your code is great. Implied pair programming sounds about right. Try the full thing sometime!
ecoffey 12y ago
Let's say the D represents the duration between when you typed that code, and when you got feedback informally at the watercooler. Pair programming, when it's working well, is just lim(D -> 0) :)

by kriro 12y ago

gedrap 12y ago

I've done that for non-trivial commits and found it much better than someone reviewing a commit alone. When you are reviewing a commit alone, it's very easy to just skim through and not be aware of details.

rudimental 12y ago

The social aspect makes coding more fun. And getting away from your keyboard is great. What you're describing to me sounds like informal code review, a high level walkthroughs of what your code does and what choices you made and why. It's a taste of pair programming. Talking through your code is great. Implied pair programming sounds about right. Try the full thing sometime!

ecoffey 12y ago

Let's say the D represents the duration between when you typed that code, and when you got feedback informally at the watercooler. Pair programming, when it's working well, is just lim(D -> 0) :)