5 ms·

Ask HN: How to Approach Pair Programming?

24 points by jerrygoyal 2y ago

I run a small remote startup with two other developers. I've heard good things about pair programming, but I have never done it myself. Any suggestions or advice on how to approach pair programming?

danielovichdk 2y ago
You will not get it right the first many times. A lot of things can happen 8n a pair programming session that has nothing to do with programming but everything to do with psychology. I urge you to take small steps. Pick a small challenge. Make sure you change who is programming, so the level change in overview versus implementation changes. When writing code you can be locked in, and that lock will tighten on a mental level when other people have insights right away, that you must listen to while programming. Take your time. Discuss and level the knowledge. Have people explain why and make sure they get time to explain without discussing. Pair programming and mob is very much about connecting the intelligence of more people but the knowledge sharing is immense. Have fun with it. Throw away branches. Start over. Discuss paths. Don't push eachother towards an unknown future just because you cannot say no to cleverness. Hope it gave you a little bit of support
capitancrunchy 2y ago
[dead]
anthony_jones 2y ago
[flagged]
zer00eyz 2y ago
So I have been doing flavors of this for almost 20 years. I can give you a system that will work. You, or your team might think that it wont work, or that you will hate it. 1. Everyone has to use the same IDE 2. Everyone needs to stop doing local dev. That first one seems like a massive hurdle. It may be one. Vim users tend to look down their nose at IDE's. IDE folks think vim users spend more time playing in vim than working. And we all want to forget about people who use VS code. (I say this having 2 open vim sessions, 2 IDE's running and used VS code today to build some firm ware). There really is one choice at this moment. Pick intellij (or one of their branded products) and code with me. Dont fuck around with VS code. VIM is NOT an option. You need everyone using the same tools so that you can work in files together (think dual cursors), or in the same tree concurrently. You also need to let someone take the wheel of your machine (think kvm/vnc) or you theirs and work effectively. Someones vimrc file is going to be disaster for you. VS code is just too incomplete and too easy to experiment with odd ui and plugins. If you have a die hard vim user then just put vim in your IDE... and lern how to toggle back and forth if loves vim that much. This gives you a fair bit of the tooling your going to need. I cant stress enough that all of you are likely going to need desks, and matched monitors... You cant have one of you in 4k and one of you in 1080. Its going to be a nightmare when you need to share screens. And your going to want to share screens. The other side of this is moving to remote dev. In an ideal world you all live in the same city, still have an office (or access to some rack space) where you could put a server and run prox mox on it. Everyone would get a VM (a whole, real VM) and then run containers/what ever they wanted on that. Why does same city/office matter. Because the spead of light is a bitch... if it takes a 1/3 of a second for the one team member across an ocean they are going to be really unhappy. If your all spread AND every one has good internet AND can poke the holes needed then set up a bunch of mini pcs's at everyone house... You can also just rent servers from someone like OVH (flat rate, unmetered bandwitdh) again pay attention to latency. Why "remote dev"? 1. easy to backup / restore (even more so with a tool like prox mox) 2. You can now take risks, having back ups, not risking your dev instance do that dumb thing. If it goes badly just turn on the backup. 3. You can do this to someone elses dev env! If your having a problem or trying to recreate a complext bug, or chase an issue through a deep stack you can all trouble shoot on the same instance. Hell you can break that, restore and be back up and running in zero time flat.... At no poit is your personal work computer, with your mail/slack/logins ever at risk of getting knocked out. The whole goal is to end up with a LOT of parity and a lot of access. You all managed to agree on a programing language, a data base etc... the rest of this is just furthering that standardization. It is going to feel weird, it is going to be rough the first two weeks but if you spend a lot of time with open voice chat and accessing and looking and making an effort to be involved in each others work your going to find you get a LOT of productivity gains. It is a tough level of collaboration to maintain your going to spend the first month forcing it for an hour a day for 3 days a week. Your going to spend a bit of time over indulging (where you end up spectating too much) ... when you all get comfortable with it the exchanges just turn into "hey can you look at" for 5 mins here and 10 there with some weekly catch ups, group code reviews and really paring for the gnarly changes.
- laminatedsmore 2y ago
  That's interesting, thanks for sharing. It's got me interested in trying this out for myself, do you happen to have / know of any other writing about workflows for setting up remote dev environments using prox mox?
  - zer00eyz 2y ago
    * Your remote dev environment doesn't have to be that remote. If it's just you using it, it might be worth it to have that box sitting in a corner at home. You could start out with a 99 dollar nuc, or the old PC you have sitting around, or a cheap desk top, or your companies casts offs (ask, you might be surprised what is getting chucked. * Prox mox is great, but it's just a pretty GUI on top of some standard linux tools. My adventure down this path started when XEN was the new hotness and it was being run on dell hardware. Pick your poison here. * VM > Containers. Your host OS doesn't have to match your host os in prod. Your VM should match your host OS in prod. If you want to run containers on that go for it, but I would work with more VM's... The moment you need to jam something into a container for debugging reasons (profiler, network monitor) the VM will have instantly won (cause your logging in and running apt/yum).... * Find a style that works for you. How do you get your code from your dev system to where it needs to be? Fuse, Rsync, SCP, SFTP, does your IDE allow for remote dev (and are the systems close enough).... * Figure out how you're going to deal with scripting: bash works great and you can do a lot with it, and make can be helpful. Sometimes you need more than bash (sometimes bash is the wrong tool)... There are a million choices like ansible, chef, puppet... you can sling around biarys (go/zig/rust)... And if your python/ruby/node, you can just install that everywhere. Candidly "portable binary" and a little bash has become the big winner here. No matter what you read or look at its going to be a month where you feel "unproductive" cause your screwing around with remote dev. In that regard treat it like a new IDE getting set up or learning a new programing language. The reality is that unless you feel like your already a systems admin your going to spend a fair bit of time becoming intimate with infrastructure. I now just have 6 core 12 thread 128gb am4 sitting in a corner for most of my day to day work. I can clone environments, make risky changes, run tests against them, and then go back work without being out of commission. When I do have compile tasks, those aren't competing with me responding to emails or doing a code review on my personal machine. The pain of setup opens up a LOT of "I can run this experiment" because you're NOT going to mess up your workflow for hours or a day doing them.
eps 2y ago
What is the problem you are hoping to resolve with this?
- android521 2y ago
  not op but we use pair programming because 1. pair programming help both to focus and do deep work. When working on our own, we are often distracted or procrastinated. Most people go to office for 8 hours but most would be productive if they can get 3 hours of deep work done with extreme focus. 2. different set of eyes/ideas can help speed up building or solving problems. 3. if someone quits, at least there i one other person who can quickly pick up the tasks
ravenstine 2y ago
If you've never done it yourself, then the answer is right in front of you. Before you try to make pair programming happen with your developers, a move that is fitting of the boss from Dilbert comics, I suggest you work on some of your own programming tasks and ask one of your developers to help you figure something out. Doesn't really matter if you aren't that skilled. Just find a harmless task you can do that isn't critical but can help you facilitate pairing as a culture. If it's clearly beneficial, then there's a decent chance your developers will simply start doing it amongst themselves. However, pairing doesn't magically create good code, better products, or more efficient developers. If your devs don't take on pair programming, then it's in your best interest to accept that it's not for them. Everyone has a different style of being productive, and for some that means deep focus and not playing backseat driver. In any case, definitely don't try to push pair programming on them without having experienced it yourself. At the very least, ask your developers what they think about pair programming and try to get as honest an opinion as you can. Chances are they actually have opinions on it.
sandreas 2y ago
My advice: While I find TDD is not a good practise for all day problems, it has its good parts for educational purposes. Pair programming is one of them. 1. Start with planning a coding dojo (about 2-3 hours), invite the whole team 2. Start a small theory session (15 minutes) about TDD and Pair-Programming essentials when starting the dojo (someone of you has to research, build knowledge and prepare beforehand) 3. Select one pair - the others are watching (in your case 1 other person) 4. Start the TDD cycle with your challenge (e.g. fizzbuzz) - Write a failing test, switch driver, fix the test, refactor, write next failing test, switch driver, repeat 5. Urge yourself and your partner to communicate (talk about what your doing atm), focus on the method not the problem and remember to stay in the roles (driver writes code, navigator manages tasks / todos) 6. After 15 minutes Change pairs to devs, who haven't been practising yet 7. Repeat until your dojo time is over This way you can educate yourself without focusing on your current work problems, but having fun focusing on the TDD and pair programming part. Knowledge transfer is also guaranteed, because the ones that don't pair-program will at least look at what the others are doing. After you've built some knowledge (after around 2 or 3 dojos), try to do 1h pair programming sessions (no longer - without the need of TDD) in your all-day work. Set a clock timer to around 10 minutes, so you don't forget to switch driver and navigator. I would not start with sessions > 1h, because pair programming can be pretty exhausting when you start. Have fun :-)
nunez 2y ago
If you're that small and are all devs, you're probably already doing some parts of it!
jerrygoyal 2y ago
I found these links helpful: https://tuple.app/pair-programming-guide/ https://tuple.app/pair-programming-guide/ https://martinfowler.com/articles/on-pair-programming.html https://martinfowler.com/articles/on-pair-programming.html
mharig 2y ago
I think pair programming cannot be made cost effective. I am quite a fan of pair debugging.
sureglymop 2y ago
When I had to go to the mandatory army service, on the first day we were told "you will always work with at least one other person and never be solely responsible for anything". I guess the army can afford it here since the service is mandatory. This is good in my opinion. In a team of two, there is not only the opportunity to help each other but also shared responsibility and not wanting to "get your coworker in trouble". So it would be interesting to see a company try radical pair programming. People coding and learning together always. Of course there would be some logistical difficulties but overall it would be interesting.
gtirloni 2y ago
Please consider some people might not enjoy working in that arrangement. You can try to convince them by showing concrete benefits (for them or the company). Some people won't have the personality for that or be neurodivergent enough that there is no way this will work for them.
brudgers 2y ago
Talk to the other two developers because what is going to work is specific to the three of you. Figure out what it means collectively. Theory doesn't matter. Other people's experience doesn't matter. Buy-in is all that really matters. Without an ongoing process, there's nothing to improve. Good luck.
NewByteHacker 2y ago
Decomposing goals reasonably is the key.

24 points by jerrygoyal 2y ago

I run a small remote startup with two other developers. I've heard good things about pair programming, but I have never done it myself. Any suggestions or advice on how to approach pair programming?

danielovichdk 2y ago

You will not get it right the first many times. A lot of things can happen 8n a pair programming session that has nothing to do with programming but everything to do with psychology. I urge you to take small steps. Pick a small challenge. Make sure you change who is programming, so the level change in overview versus implementation changes. When writing code you can be locked in, and that lock will tighten on a mental level when other people have insights right away, that you must listen to while programming. Take your time. Discuss and level the knowledge. Have people explain why and make sure they get time to explain without discussing. Pair programming and mob is very much about connecting the intelligence of more people but the knowledge sharing is immense. Have fun with it. Throw away branches. Start over. Discuss paths. Don't push eachother towards an unknown future just because you cannot say no to cleverness. Hope it gave you a little bit of support

capitancrunchy 2y ago

[dead]

anthony_jones 2y ago

[flagged]

zer00eyz 2y ago

So I have been doing flavors of this for almost 20 years. I can give you a system that will work. You, or your team might think that it wont work, or that you will hate it. 1. Everyone has to use the same IDE 2. Everyone needs to stop doing local dev. That first one seems like a massive hurdle. It may be one. Vim users tend to look down their nose at IDE's. IDE folks think vim users spend more time playing in vim than working. And we all want to forget about people who use VS code. (I say this having 2 open vim sessions, 2 IDE's running and used VS code today to build some firm ware). There really is one choice at this moment. Pick intellij (or one of their branded products) and code with me. Dont fuck around with VS code. VIM is NOT an option. You need everyone using the same tools so that you can work in files together (think dual cursors), or in the same tree concurrently. You also need to let someone take the wheel of your machine (think kvm/vnc) or you theirs and work effectively. Someones vimrc file is going to be disaster for you. VS code is just too incomplete and too easy to experiment with odd ui and plugins. If you have a die hard vim user then just put vim in your IDE... and lern how to toggle back and forth if loves vim that much. This gives you a fair bit of the tooling your going to need. I cant stress enough that all of you are likely going to need desks, and matched monitors... You cant have one of you in 4k and one of you in 1080. Its going to be a nightmare when you need to share screens. And your going to want to share screens. The other side of this is moving to remote dev. In an ideal world you all live in the same city, still have an office (or access to some rack space) where you could put a server and run prox mox on it. Everyone would get a VM (a whole, real VM) and then run containers/what ever they wanted on that. Why does same city/office matter. Because the spead of light is a bitch... if it takes a 1/3 of a second for the one team member across an ocean they are going to be really unhappy. If your all spread AND every one has good internet AND can poke the holes needed then set up a bunch of mini pcs's at everyone house... You can also just rent servers from someone like OVH (flat rate, unmetered bandwitdh) again pay attention to latency. Why "remote dev"? 1. easy to backup / restore (even more so with a tool like prox mox) 2. You can now take risks, having back ups, not risking your dev instance do that dumb thing. If it goes badly just turn on the backup. 3. You can do this to someone elses dev env! If your having a problem or trying to recreate a complext bug, or chase an issue through a deep stack you can all trouble shoot on the same instance. Hell you can break that, restore and be back up and running in zero time flat.... At no poit is your personal work computer, with your mail/slack/logins ever at risk of getting knocked out. The whole goal is to end up with a LOT of parity and a lot of access. You all managed to agree on a programing language, a data base etc... the rest of this is just furthering that standardization. It is going to feel weird, it is going to be rough the first two weeks but if you spend a lot of time with open voice chat and accessing and looking and making an effort to be involved in each others work your going to find you get a LOT of productivity gains. It is a tough level of collaboration to maintain your going to spend the first month forcing it for an hour a day for 3 days a week. Your going to spend a bit of time over indulging (where you end up spectating too much) ... when you all get comfortable with it the exchanges just turn into "hey can you look at" for 5 mins here and 10 there with some weekly catch ups, group code reviews and really paring for the gnarly changes.

laminatedsmore 2y ago
That's interesting, thanks for sharing. It's got me interested in trying this out for myself, do you happen to have / know of any other writing about workflows for setting up remote dev environments using prox mox?
- zer00eyz 2y ago
  * Your remote dev environment doesn't have to be that remote. If it's just you using it, it might be worth it to have that box sitting in a corner at home. You could start out with a 99 dollar nuc, or the old PC you have sitting around, or a cheap desk top, or your companies casts offs (ask, you might be surprised what is getting chucked. * Prox mox is great, but it's just a pretty GUI on top of some standard linux tools. My adventure down this path started when XEN was the new hotness and it was being run on dell hardware. Pick your poison here. * VM > Containers. Your host OS doesn't have to match your host os in prod. Your VM should match your host OS in prod. If you want to run containers on that go for it, but I would work with more VM's... The moment you need to jam something into a container for debugging reasons (profiler, network monitor) the VM will have instantly won (cause your logging in and running apt/yum).... * Find a style that works for you. How do you get your code from your dev system to where it needs to be? Fuse, Rsync, SCP, SFTP, does your IDE allow for remote dev (and are the systems close enough).... * Figure out how you're going to deal with scripting: bash works great and you can do a lot with it, and make can be helpful. Sometimes you need more than bash (sometimes bash is the wrong tool)... There are a million choices like ansible, chef, puppet... you can sling around biarys (go/zig/rust)... And if your python/ruby/node, you can just install that everywhere. Candidly "portable binary" and a little bash has become the big winner here. No matter what you read or look at its going to be a month where you feel "unproductive" cause your screwing around with remote dev. In that regard treat it like a new IDE getting set up or learning a new programing language. The reality is that unless you feel like your already a systems admin your going to spend a fair bit of time becoming intimate with infrastructure. I now just have 6 core 12 thread 128gb am4 sitting in a corner for most of my day to day work. I can clone environments, make risky changes, run tests against them, and then go back work without being out of commission. When I do have compile tasks, those aren't competing with me responding to emails or doing a code review on my personal machine. The pain of setup opens up a LOT of "I can run this experiment" because you're NOT going to mess up your workflow for hours or a day doing them.

eps 2y ago

What is the problem you are hoping to resolve with this?

android521 2y ago
not op but we use pair programming because 1. pair programming help both to focus and do deep work. When working on our own, we are often distracted or procrastinated. Most people go to office for 8 hours but most would be productive if they can get 3 hours of deep work done with extreme focus. 2. different set of eyes/ideas can help speed up building or solving problems. 3. if someone quits, at least there i one other person who can quickly pick up the tasks

ravenstine 2y ago

If you've never done it yourself, then the answer is right in front of you. Before you try to make pair programming happen with your developers, a move that is fitting of the boss from Dilbert comics, I suggest you work on some of your own programming tasks and ask one of your developers to help you figure something out. Doesn't really matter if you aren't that skilled. Just find a harmless task you can do that isn't critical but can help you facilitate pairing as a culture. If it's clearly beneficial, then there's a decent chance your developers will simply start doing it amongst themselves. However, pairing doesn't magically create good code, better products, or more efficient developers. If your devs don't take on pair programming, then it's in your best interest to accept that it's not for them. Everyone has a different style of being productive, and for some that means deep focus and not playing backseat driver. In any case, definitely don't try to push pair programming on them without having experienced it yourself. At the very least, ask your developers what they think about pair programming and try to get as honest an opinion as you can. Chances are they actually have opinions on it.

sandreas 2y ago

My advice: While I find TDD is not a good practise for all day problems, it has its good parts for educational purposes. Pair programming is one of them. 1. Start with planning a coding dojo (about 2-3 hours), invite the whole team 2. Start a small theory session (15 minutes) about TDD and Pair-Programming essentials when starting the dojo (someone of you has to research, build knowledge and prepare beforehand) 3. Select one pair - the others are watching (in your case 1 other person) 4. Start the TDD cycle with your challenge (e.g. fizzbuzz) - Write a failing test, switch driver, fix the test, refactor, write next failing test, switch driver, repeat 5. Urge yourself and your partner to communicate (talk about what your doing atm), focus on the method not the problem and remember to stay in the roles (driver writes code, navigator manages tasks / todos) 6. After 15 minutes Change pairs to devs, who haven't been practising yet 7. Repeat until your dojo time is over This way you can educate yourself without focusing on your current work problems, but having fun focusing on the TDD and pair programming part. Knowledge transfer is also guaranteed, because the ones that don't pair-program will at least look at what the others are doing. After you've built some knowledge (after around 2 or 3 dojos), try to do 1h pair programming sessions (no longer - without the need of TDD) in your all-day work. Set a clock timer to around 10 minutes, so you don't forget to switch driver and navigator. I would not start with sessions > 1h, because pair programming can be pretty exhausting when you start. Have fun :-)

nunez 2y ago

If you're that small and are all devs, you're probably already doing some parts of it!

jerrygoyal 2y ago

I found these links helpful: https://tuple.app/pair-programming-guide/ https://tuple.app/pair-programming-guide/ https://martinfowler.com/articles/on-pair-programming.html https://martinfowler.com/articles/on-pair-programming.html

mharig 2y ago

I think pair programming cannot be made cost effective. I am quite a fan of pair debugging.

sureglymop 2y ago

When I had to go to the mandatory army service, on the first day we were told "you will always work with at least one other person and never be solely responsible for anything". I guess the army can afford it here since the service is mandatory. This is good in my opinion. In a team of two, there is not only the opportunity to help each other but also shared responsibility and not wanting to "get your coworker in trouble". So it would be interesting to see a company try radical pair programming. People coding and learning together always. Of course there would be some logistical difficulties but overall it would be interesting.

gtirloni 2y ago

Please consider some people might not enjoy working in that arrangement. You can try to convince them by showing concrete benefits (for them or the company). Some people won't have the personality for that or be neurodivergent enough that there is no way this will work for them.

brudgers 2y ago

Talk to the other two developers because what is going to work is specific to the three of you. Figure out what it means collectively. Theory doesn't matter. Other people's experience doesn't matter. Buy-in is all that really matters. Without an ongoing process, there's nothing to improve. Good luck.

NewByteHacker 2y ago

Decomposing goals reasonably is the key.