4 ms·

There are some pre-requisites to Pair programming. That you need to have a well defined task, that you need not be bogged down by insane deadlines and can affor

by sh87 8y ago

There are some pre-requisites to Pair programming. That you need to have a well defined task, that you need not be bogged down by insane deadlines and can afford to have 2 people work on the same thing and both need to be well versed at the task at hand to live up to the promise of productivity. My experience pair programming for a year was sh*tty enough to never consider it again unless I have these pre-reqs met. I'd much rather split tasks, work independently and then touch base often.

BurningFrog 8y ago
> you need to have a well defined task, that you need not be bogged down by insane deadlines Aren't these pre-requisites to all work? How does working alone solve them? The thing that's often overlooked is that pair programming is a skill, and you need to learn it to do it well. Just putting two novice pair programmers at a computer and asking them to "just do it" will usually result in a lot of frustration. I was fortunate to be pairing with a lot of seasoned pros in my first time.
- optimiz3 8y ago
  Not all problems are well defined. Generally the more business impact you have, the more undefined your work is.
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 ago
  If that is how you define pair programming, how is pair programming different than just working with someone on a problem? Legit question.
  - elcomet 8y ago
    Pair programming is literally working with someone on a programming problem.
  - catwind7 8y ago
    yeah 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
saghm 8y ago
I haven't had a job that required pair programming, but I've found it can be a pretty useful tool in certain circumstances. There have been a number of times when a colleague and I have naturally fell into pair programming for tasks, normally starting with us just sharing ideas and one of us eventually jumping in front of a keyboard and the two of us trying out several ideas live. It certainly isn't as formal as "pair programming" normally might imply, but as someone who's hasn't been in the industry all that long, I've found the times that one done it with more senior teammates to be insightful, as well as pretty effective for certain types of tasks.
- koala_man 8y ago
  I'd rather have a design session and a code review in that case. What I've found pair programming useful for is tooling and workflow. When working that closely you'll notice when they hit a few keys and are suddenly in the right file, and you go "wait, what did you just do?" and they tell you about this great new Vim plugin. Inversely, they start doing something really manual and you can say "hey, I do this a lot do I wrote this utility script that automates it"
deleted 8y ago
[deleted]

by sh87 8y ago

BurningFrog 8y ago

> you need to have a well defined task, that you need not be bogged down by insane deadlines Aren't these pre-requisites to all work? How does working alone solve them? The thing that's often overlooked is that pair programming is a skill, and you need to learn it to do it well. Just putting two novice pair programmers at a computer and asking them to "just do it" will usually result in a lot of frustration. I was fortunate to be pairing with a lot of seasoned pros in my first time.

optimiz3 8y ago
Not all problems are well defined. Generally the more business impact you have, the more undefined your work is.

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 ago
If that is how you define pair programming, how is pair programming different than just working with someone on a problem? Legit question.
- elcomet 8y ago
  Pair programming is literally working with someone on a programming problem.
- catwind7 8y ago
  yeah 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

saghm 8y ago

I haven't had a job that required pair programming, but I've found it can be a pretty useful tool in certain circumstances. There have been a number of times when a colleague and I have naturally fell into pair programming for tasks, normally starting with us just sharing ideas and one of us eventually jumping in front of a keyboard and the two of us trying out several ideas live. It certainly isn't as formal as "pair programming" normally might imply, but as someone who's hasn't been in the industry all that long, I've found the times that one done it with more senior teammates to be insightful, as well as pretty effective for certain types of tasks.

koala_man 8y ago
I'd rather have a design session and a code review in that case. What I've found pair programming useful for is tooling and workflow. When working that closely you'll notice when they hit a few keys and are suddenly in the right file, and you go "wait, what did you just do?" and they tell you about this great new Vim plugin. Inversely, they start doing something really manual and you can say "hey, I do this a lot do I wrote this utility script that automates it"

deleted 8y ago

[deleted]