4 ms·

Well, it certainly seems difficult to pair program for 8 hours a day. That to me indicates that people don't understand the point of it. For me, pair programmi

by hadsed 9y ago

Well, it certainly seems difficult to pair program for 8 hours a day. That to me indicates that people don't understand the point of it. For me, pair programming with the right person always resulted in a quantum leap in my knowledge and skills. This was true for the astrophysics professor who taught me about Linux, RAID, Fortran, and modelling colliding galaxies, it was true of the electrical engineer who wrote driver software for a DNA sequencer, and it was also true for the guy who would keep postgres from falling over every damn morning at a startup whose data was just exploding. Even today, when someone new comes to a project we sit down every day or so for a few weeks and we code. The amount you can gain just by watching a pro is incredibly valuable. It's all the little things, the tiny decisions they make, the way they think about problems and solve them. You'll get a glimpse of the reasoning and experience behind their philosophies. These are not things you can easily see through a pull request, in a classroom, or even in meetings. For me, it is the ultimate kind of mentorship.

abritinthebay 9y ago
Most people don’t understand Pair Programming. Most people don’t understand most Agile/XP practices though. They will often write lengthy blog posts about how said practices don’t work while also illustrating they never did them well in the first place though.
- vonmoltke 9y ago
  They also often write lengthy blog posts about how well it worked for their specific situation and then pontificating about how it generalizes to all software development.
  - abritinthebay 9y ago
    Agile principles generalize to all software development. The specific application of those principles at one company won’t. That’s the core difference people miss. Of course then there is the difference between “software development” and “one individual programmer”. Not all programmers will gel with Agile stuff as well as the next one. That’s why it’s not supposed to be rigid (it often is when done poorly). But yes, an understanding of the principles is required to translate them into practices for a team. Rigid adherence to Scrum or XP is missing the point. For a good look at a way one company took the principles of Agile and applied them in a very effective but utterly idiosyncratic way... look at Spotify. Pt 1: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ https://labs.spotify.com/2014/03/27/spotify-engineering-cult... Pt 2: https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/ https://labs.spotify.com/2014/09/20/spotify-engineering-cult...
valuearb 9y ago
Learning/teaching is a valuable benefit of pair programming. Higher quality code is another. Being able to finish a critical section of code faster is the last benefit. Slower development is a cost. Less enjoyable development is a cost. The work required to engage a junior dev is a cost. Being required to code at the same times is a cost. There isn’t a one size fits all solution to every problem. I can mentor a junior by reviewing her pull requests carefully, on my own time schedule, and send her the notes. It’s more effective if we pair the fixes, cause she can ask questions more easily and we can have more wide ranging discussions. But I’d quit if I had to pair with her every day, trying to read code off her tiny, dirty laptop screen and constantly having to corral her impulse to instantly apply every suggestion I make, before I’m even done saying it.

by hadsed 9y ago

abritinthebay 9y ago

Most people don’t understand Pair Programming. Most people don’t understand most Agile/XP practices though. They will often write lengthy blog posts about how said practices don’t work while also illustrating they never did them well in the first place though.

vonmoltke 9y ago
They also often write lengthy blog posts about how well it worked for their specific situation and then pontificating about how it generalizes to all software development.
- abritinthebay 9y ago
  Agile principles generalize to all software development. The specific application of those principles at one company won’t. That’s the core difference people miss. Of course then there is the difference between “software development” and “one individual programmer”. Not all programmers will gel with Agile stuff as well as the next one. That’s why it’s not supposed to be rigid (it often is when done poorly). But yes, an understanding of the principles is required to translate them into practices for a team. Rigid adherence to Scrum or XP is missing the point. For a good look at a way one company took the principles of Agile and applied them in a very effective but utterly idiosyncratic way... look at Spotify. Pt 1: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ https://labs.spotify.com/2014/03/27/spotify-engineering-cult... Pt 2: https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/ https://labs.spotify.com/2014/09/20/spotify-engineering-cult...

valuearb 9y ago

Learning/teaching is a valuable benefit of pair programming. Higher quality code is another. Being able to finish a critical section of code faster is the last benefit. Slower development is a cost. Less enjoyable development is a cost. The work required to engage a junior dev is a cost. Being required to code at the same times is a cost. There isn’t a one size fits all solution to every problem. I can mentor a junior by reviewing her pull requests carefully, on my own time schedule, and send her the notes. It’s more effective if we pair the fixes, cause she can ask questions more easily and we can have more wide ranging discussions. But I’d quit if I had to pair with her every day, trying to read code off her tiny, dirty laptop screen and constantly having to corral her impulse to instantly apply every suggestion I make, before I’m even done saying it.