3 ms·
a lot of this depends on the dynamics of the team. i don't think pair programming necessarily means typing 100% of the time. I get a ton of value in tackling a
by catwind7 8y ago
a lot of this depends on the dynamics of the team.
i don't think pair programming necessarily means typing 100% of the time. I get a ton of value in tackling a very ill-defined task with another member of my team, especially in the design / architecture phase where I find that a lot of engineers tend to over-think and over-engineer a task.
i don't want to discount your experience tho - i def. have moments where i absolutely do not want to pair, but i do think it's a practice that is super context (team) sensitive
- ergothus 8y agoIf that is how you define pair programming, how is pair programming different than just working with someone on a problem? Legit question.
- elcomet 8y agoPair programming is literally working with someone on a programming problem.
- catwind7 8y agoyeah i think that's a fair question. i think while the extreme programming community may define it as a practice with a particular set of guidelines, ultimately it's about working effectively with another programmer. sometimes that means bucking the rules of whatever the methodology prescribes and doing what works for your team. for example: xp people tend to suggest frequent pair rotations in order to spread knowledge (faster?). I know half my team, though advocates of pair programming, would be pretty unhappy with that given the costs of context switching. maybe some people will point at that and say we're not really pair programming /shrug