4 ms·

I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases a

I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases and trying to fix technical debt while under time pressure to launch a new feature. I often see things that, I can only imagine, were written by some junior dev trying to impress their boss by just hacking something together and throwing it over the wall. More and more I wish that code had been written via pair programming, where the other (hopefully more senior and judicious) developer could have, perhaps by only their mere presence, prevented the hack dev from doing what they did.

rajin444 5y ago
Code reviews prevent this as well, without all the overhead incurred by pair programming. I think pair programming has its uses, but unless the 2 working together are on the same level it's really hard to get into "flow".
- steelframe 5y ago
  > Code reviews prevent this as well, without all the overhead incurred by pair programming. I'm a big believer in correcting errant behavior in the moment. Simply the presence of an overseer can coerce a developer to avoid taking shortcuts with the hope that it might go overlooked in an asynchronous code review.
- fao_ 5y ago
  Do they? I am on a team of two, and yet, I rarely have time to audit code that my fellow has written, simply because the rest of the day demands other tasks to be focused upon
  - yjftsjthsd-h 5y ago
    If you don't have time to review, would you have time to pair? I think time constraints are a deeper problem
    - fao_ 5y ago
      You would be surprised
ardit33 5y ago
That's what code reviews are for. You don't need pair programing for that. Places like google go even beyond by having a 'readibility' pass score for the code to be able to ship. Pair programing is something from the early 2000s, where code review tools were non-existent (I remember, people would just email diffs to each other), back in the day.
- toomanybeersies 5y ago
  In my experience, code review often becomes a rubber stamping exercise. Reviewers only add trivial feedback and stop short of adding actual constructive criticism or feedback, either because they don't want to look like an arsehole, or because they don't have time. That said, it's not an intrinsic problem with code review, but a team culture problem.

rajin444 5y ago

Code reviews prevent this as well, without all the overhead incurred by pair programming. I think pair programming has its uses, but unless the 2 working together are on the same level it's really hard to get into "flow".

steelframe 5y ago
> Code reviews prevent this as well, without all the overhead incurred by pair programming. I'm a big believer in correcting errant behavior in the moment. Simply the presence of an overseer can coerce a developer to avoid taking shortcuts with the hope that it might go overlooked in an asynchronous code review.
fao_ 5y ago
Do they? I am on a team of two, and yet, I rarely have time to audit code that my fellow has written, simply because the rest of the day demands other tasks to be focused upon
- yjftsjthsd-h 5y ago
  If you don't have time to review, would you have time to pair? I think time constraints are a deeper problem
  - fao_ 5y ago
    You would be surprised

ardit33 5y ago

That's what code reviews are for. You don't need pair programing for that. Places like google go even beyond by having a 'readibility' pass score for the code to be able to ship. Pair programing is something from the early 2000s, where code review tools were non-existent (I remember, people would just email diffs to each other), back in the day.

toomanybeersies 5y ago
In my experience, code review often becomes a rubber stamping exercise. Reviewers only add trivial feedback and stop short of adding actual constructive criticism or feedback, either because they don't want to look like an arsehole, or because they don't have time. That said, it's not an intrinsic problem with code review, but a team culture problem.